From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitakerNeternity.demon.co.uk.demon.co.uk ("Russell E. Whitaker")
Date: Mon, 21 Sep 1992 13:24:27 +0000
Subject: Long but good: Hammill on encryption
Message-ID: <717081867snx@eternity.demon.co.uk.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


The following is the text of a *very* interesting speech
given in 1987 by mathematician Chuck Hammill.  The Soviet
Union is mentioned; while this may be a little dated, there's
always China... and Cuba... and a few other places...

Enjoy,

Russell



  FROM CROSSBOWS TO CRYPTOGRAPHY:  THWARTING THE STATE VIA
                     TECHNOLOGY
 
  Given at the Future of Freedom Conference, November 1987
 
 
     You   know,   technology--and   particularly   computer
technology--has often gotten a bad rap in  Libertarian  cir-
cles.  We tend to think of Orwell's 1984, or Terry Gilliam's
Brazil,  or  the  proximity  detectors keeping East Berlin's
slave/citizens on their own side of the border, or  the  so-
phisticated  bugging  devices  Nixon used to harass those on
his "enemies list."  Or, we recognize that for the price  of
a  ticket  on  the Concorde we can fly at twice the speed of
sound, but only if we first walk thru a magnetometer run  by
a  government  policeman, and permit him to paw thru our be-
longings if it beeps.
 
     But I think that mind-set is a mistake.   Before  there
were cattle prods, governments tortured their prisoners with
clubs  and  rubber  hoses.    Before  there  were lasers for
eavesdropping, governments used binoculars and  lip-readers.
Though  government certainly uses technology to oppress, the
evil lies not in the tools but in the wielder of the tools.
 
     In fact, technology represents one of the most  promis-
ing  avenues  available  for  re-capturing our freedoms from
those who have stolen them.  By its very nature,  it  favors
the  bright  (who can put it to use) over the dull (who can-
not).  It favors the adaptable (who are  quick  to  see  the
merit  of  the  new(  over  the sluggish (who cling to time-
tested ways).  And what two better words are  there  to  de-
scribe government bureaucracy than "dull" and "sluggish"?
 
     One  of  the  clearest,  classic triumphs of technology
over tyranny I see is  the  invention  of  the  man-portable
crossbow.   With it, an untrained peasant could now reliably
and lethally engage a target out to  fifty  meters--even  if
that  target  were  a mounted, chain-mailed knight.  (Unlike
the longbow, which, admittedly was more powerful, and  could
get  off  more shots per unit time, the crossbow required no
formal training to utilize.   Whereas the  longbow  required
elaborate  visual,  tactile  and kinesthetic coordination to
achieve any degree of accuracy, the wielder  of  a  crossbow
could simply put the weapon to his shoulder, sight along the
arrow  itself, and be reasonably assured of hitting his tar-
get.)
 
     Moreover, since just about  the  only  mounted  knights
likely  to  visit  your  average peasant would be government
soldiers and tax collectors, the utility of the  device  was
plain:    With it, the common rabble could defend themselves
not only against one another, but against their governmental
masters.   It was the  medieval  equivalent  of  the  armor-
piercing  bullet,  and, consequently, kings and priests (the
medieval equivalent of a  Bureau  of  Alcohol,  Tobacco  and
Crossbows)  threatened  death  and  excommunication, respec-
tively, for its unlawful possession.
 
     Looking at later developments, we  see  how  technology
like  the  firearm--particularly the repeating rifle and the
handgun, later followed by the Gatling gun and more advanced
machine guns--radically altered the balance of interpersonal
and inter-group power.  Not without reason was the Colt  .45
called "the equalizer."  A frail dance-hall hostess with one
in  her  possession  was  now  fully able to protect herself
against the brawniest roughneck in any saloon.    Advertise-
ments  for  the period also reflect the merchandising of the
repeating cartridge  rifle  by  declaring  that  "a  man  on
horseback,  armed with one of these rifles, simply cannot be
captured."  And, as long as his captors  were  relying  upon
flintlocks  or  single-shot rifles, the quote is doubtless a
true one.
 
     Updating now to  the  present,  the  public-key  cipher
(with  a  personal  computer to run it) represents an equiv-
alent quantum leap--in a defensive weapon.    Not  only  can
such  a technique be used to protect sensitive data in one's
own possession, but it can also permit two strangers to  ex-
change   information   over   an   insecure   communications
channel--a  wiretapped   phone   line,   for   example,   or
skywriting, for that matter)--without ever having previously
met  to  exchange cipher keys.   With a thousand-dollar com-
puter, you can create a cipher that  a  multi-megabuck  CRAY
X-MP  can't  crack in a year.  Within a few years, it should
be economically feasible to similarly encrypt voice communi-
cations; soon after that, full-color digitized video images.
Technology will not only have made wiretapping obsolete,  it
will  have  totally demolished government's control over in-
formation transfer.
 
     I'd like to take just a moment to sketch the  mathemat-
ics  which makes this principle possible.  This algorithm is
called the RSA algorithm, after Rivest, Shamir, and  Adleman
who  jointly created it.  Its security derives from the fact
that, if a very large number is  the  product  of  two  very
large  primes,  then it is extremely difficult to obtain the
two prime factors from analysis  of  their  product.    "Ex-
tremely"  in  the  sense that if primes  p  and  q  have 100
digits apiece, then their 200-digit product cannot  in  gen-
eral be factored in less than 100 years by the most powerful
computer now in existence.
 
     The  "public" part of the key consists of (1) the prod-
uct  pq  of the two large primes p and q, and (2)  one  fac-
tor,  call it  x  , of the product  xy  where  xy = {(p-1) *
(q-1) + 1}.  The "private" part of the key consists  of  the
other factor  y.
 
     Each  block of the text to be encrypted is first turned
into an integer--either by using ASCII,  or  even  a  simple
A=01,  B=02,  C=03, ... , Z=26 representation.  This integer
is then raised to the power  x (modulo pq) and the resulting
integer is then sent as the encrypted message.  The receiver
decrypts by taking this integer to the  (secret)  power    y
(modulo  pq).  It can be shown that this process will always
yield the original number started with.
 
     What makes this a groundbreaking development,  and  why
it  is  called  "public-key"  cryptography,"  is  that I can
openly publish the product  pq and the number   x   ,  while
keeping  secret  the number  y  --so that anyone can send me
an encrypted message, namely
                       x
                     a    (mod pq)  ,
but only I can recover the original message  a  , by  taking
what  they  send, raising it to the power  y  and taking the
result (mod pq).  The risky step (meeting to exchange cipher
keys) has been eliminated.  So people who may not even trust
each other enough to want to meet, may  still  reliably  ex-
change  encrypted  messages--each  party having selected and
disseminated his own  pq  and his  x  ,   while  maintaining
the secrecy of his own  y.
 
     Another benefit of this scheme is the notion of a "dig-
ital signature," to enable one to authenticate the source of
a given message.  Normally, if I want to send you a message,
I raise my plaintext  a  to your x and take the result  (mod
your pq)  and send that.
 
    However,  if in my message, I take the plaintext  a and
raise it to my (secret) power  y  , take the result  (mod my
pq), then raise that result to your x   (mod  your  pq)  and
send this, then even after you have normally "decrypted" the
message,  it  will still look like garbage.  However, if you
then raise it to my public power x   , and take  the  result
(mod  my public pq  ), so you will not only recover the ori-
ginal plaintext message, but you will know that no one but I
could have sent it to you (since no one else knows my secret
y).
 
     And these are the very concerns by the way that are to-
day tormenting the Soviet Union about the whole question  of
personal  computers.    On the one hand, they recognize that
American schoolchildren are right now growing up  with  com-
puters  as commonplace as sliderules used to be--more so, in
fact, because there are things computers can do  which  will
interest  (and instruct) 3- and 4-year-olds.  And it is pre-
cisely these students who one generation hence will be going
head-to-head against their Soviet  counterparts.    For  the
Soviets  to  hold  back might be a suicidal as continuing to
teach swordsmanship  while  your  adversaries  are  learning
ballistics.    On  the  other hand, whatever else a personal
computer may be, it is also an exquisitely efficient copying
machine--a floppy disk will hold upwards of 50,000 words  of
text,  and  can  be  copied in a couple of minutes.  If this
weren't threatening enough, the computer that  performs  the
copy  can also encrypt the data in a fashion that is all but
unbreakable.  Remember that in Soviet society  publicly  ac-
cessible  Xerox  machines are unknown.   (The relatively few
copying machines in existence  are  controlled  more  inten-
sively than machine guns are in the United States.)
 
     Now  the  "conservative" position is that we should not
sell these computers to the Soviets, because they could  use
them  in weapons systems.  The "liberal" position is that we
should sell them, in  the  interests  of  mutual  trade  and
cooperation--and  anyway,  if  we don't make the sale, there
will certainly be some other nation willing to.
 
     For my part, I'm ready to suggest that the  Libertarian
position should be to give them to the Soviets for free, and
if  necessary, make them take them . . . and if that doesn't
work load up an SR-71  Blackbird  and  air  drop  them  over
Moscow in the middle of the night.  Paid for by private sub-
scription, of course, not taxation . . . I confess that this
is not a position that has gained much support among members
of  the conventional left-right political spectrum, but, af-
ter all, in the words of one of Illuminatus's characters, we
are political non-Euclideans:   The shortest distance  to  a
particular  goal may not look anything like what most people
would consider a "straight line."    Taking  a  long  enough
world-view,  it is arguable that breaking the Soviet govern-
ment monopoly on information transfer could better  lead  to
the enfeeblement and, indeed, to the ultimate dissolution of
the Soviet empire than would the production of another dozen
missiles aimed at Moscow.
 
     But  there's  the rub:  A "long enough" world view does
suggest that the evil, the oppressive, the coercive and  the
simply  stupid  will "get what they deserve," but what's not
immediately clear is how the rest of  us  can  escape  being
killed, enslaved, or pauperized in the process.
 
    When  the  liberals and other collectivists began to at-
tack freedom, they possessed a reasonably  stable,  healthy,
functioning economy, and almost unlimited time to proceed to
hamstring   and   dismantle  it.    A  policy  of  political
gradualism was at least  conceivable.    But  now,  we  have
patchwork  crazy-quilt  economy held together by baling wire
and spit.  The state not only taxes us to  "feed  the  poor"
while also inducing farmers to slaughter milk cows and drive
up food prices--it then simultaneously turns around and sub-
sidizes research into agricultural chemicals designed to in-
crease  yields of milk from the cows left alive.  Or witness
the fact that a decline in the price of oil is considered as
potentially frightening as a comparable increase a few years
ago.  When the price went up,  we  were  told,  the  economy
risked  collapse for for want of energy.  The price increase
was called the "moral equivalent of war" and the Feds  swung
into  action.    For the first time in American history, the
speed at which you drive your car to work in the morning be-
came an issue of Federal concern.   Now, when the  price  of
oil  drops, again we risk problems, this time because Ameri-
can oil companies and Third World  basket-case  nations  who
sell  oil  may  not  be  able to ever pay their debts to our
grossly over-extended banks.  The suggested panacea is  that
government  should now re-raise the oil prices that OPEC has
lowered, via a new oil tax.  Since the government is seeking
to raise oil prices to about the same extent  as  OPEC  did,
what  can we call this except the "moral equivalent of civil
war--the government against its own people?"
 
     And, classically, in international trade, can you imag-
ine any entity in the world except  a  government  going  to
court  claiming  that  a  vendor  was  selling  it goods too
cheaply and demanding not only that that naughty  vendor  be
compelled by the court to raise its prices, but also that it
be punished for the act of lowering them in the first place?
 
     So  while the statists could afford to take a couple of
hundred years to trash our  economy  and  our  liberties--we
certainly  cannot  count  on  having an equivalent period of
stability in which to reclaim them.   I contend  that  there
exists  almost  a  "black  hole"  effect in the evolution of
nation-states just as in the evolution of stars.  Once free-
dom contracts beyond a certain  minimum  extent,  the  state
warps  the fabric of the political continuum about itself to
the degree that subsequent re-emergence of  freedom  becomes
all but impossible.  A good illustration of this can be seen
in the area of so-called "welfare" payments.  When those who
sup  at the public trough outnumber (and thus outvote) those
whose taxes must replenish the trough,  then  what  possible
choice has a democracy but to perpetuate and expand the tak-
ing  from  the few for the unearned benefit of the many?  Go
down to the nearest "welfare" office, find just  two  people
on  the dole . . . and recognize that between them they form
a voting bloc that can forever outvote you on  the  question
of who owns your life--and the fruits of your life's labor.
 
     So essentially those who love liberty need an "edge" of
some  sort  if  we're ultimately going to prevail.  We obvi-
ously  can't  use  the  altruists'  "other-directedness"  of
"work,  slave, suffer, sacrifice, so that next generation of
a billion random strangers can  live  in  a  better  world."
Recognize  that, however immoral such an appeal might be, it
is nonetheless an extremely powerful one in today's culture.
If you can convince  people  to  work  energetically  for  a
"cause," caring only enough for their personal welfare so as
to  remain  alive  enough  and  healthy  enough  to continue
working--then you have a truly massive reservoir  of  energy
to draw from.  Equally clearly, this is just the sort of ap-
peal which tautologically cannot be utilized for egoistic or
libertarian goals.  If I were to stand up before you tonight
and say something like, "Listen, follow me as I enunciate my
noble "cause," contribute your money to support the "cause,"
give  up  your  free  time  to  work for the "cause," strive
selflessly to bring it about, and then (after you  and  your
children are dead) maybe your children's children will actu-
ally  live under egoism"--you'd all think I'd gone mad.  And
of course you'd be right.  Because the point I'm  trying  to
make is that libertarianism and/or egoism will be spread if,
when, and as, individual libertarians and/or egoists find it
profitable and/or enjoyable to do so.    And  probably  only
then.
 
     While I certainly do not disparage the concept of poli-
tical  action, I don't believe that it is the only, nor even
necessarily the most cost-effective path  toward  increasing
freedom  in  our time.  Consider that, for a fraction of the
investment in time, money and effort I might expend in  try-
ing  to  convince  the  state to abolish wiretapping and all
forms of censorship--I can teach every libertarian who's in-
terested  how  to   use   cryptography   to   abolish   them
unilaterally.
 
     There  is  a  maxim--a proverb--generally attributed to
the Eskimoes, which very likely most Libertarians  have  al-
ready  heard.    And while you likely would not quarrel with
the saying, you might well feel that you've heard  it  often
enough already, and that it has nothing further to teach us,
and moreover, that maybe you're even tired of hearing it.  I
shall therefore repeat it now:
 
     If you give a man a fish, the saying runs, you feed him
for a day.  But if you teach a man how to fish, you feed him
for a lifetime.
 
     Your exposure to the quote was probably in some sort of
a  "workfare"  vs.  "welfare"  context;  namely, that if you
genuinely wish to help someone in need, you should teach him
how to earn his sustenance, not simply how to  beg  for  it.
And of course this is true, if only because the next time he
is hungry, there might not be anybody around willing or even
able to give him a fish, whereas with the information on how
to fish, he is completely self sufficient.
 
     But  I  submit  that this exhausts only the first order
content of the quote, and if there were nothing  further  to
glean  from  it,  I would have wasted your time by citing it
again.  After all, it seems to have almost a crypto-altruist
slant, as though to imply that we should structure  our  ac-
tivities  so  as  to  maximize  the  benefits to such hungry
beggars as we may encounter.
 
     But consider:
 
     Suppose this Eskimo doesn't know how to  fish,  but  he
does  know  how  to hunt walruses.   You, on the other hand,
have often gone hungry while traveling thru  walrus  country
because  you  had  no idea how to catch the damn things, and
they ate most of the fish you could catch.  And now  suppose
the  two  of  you  decide to exchange information, bartering
fishing knowledge for hunting knowledge.   Well,  the  first
thing  to  observe  is  that  a  transaction  of  this  type
categorically and unambiguously refutes the Marxist  premise
that  every  trade  must  have a "winner" and a "loser;" the
idea that if one person gains, it must necessarily be at the
"expense" of another person who loses.  Clearly, under  this
scenario, such is not the case.  Each party has gained some-
thing  he  did  not have before, and neither has been dimin-
ished in any way.  When it comes to exchange of  information
(rather  than material objects) life is no longer a zero-sum
game.  This is an extremely powerful notion.   The  "law  of
diminishing   returns,"   the  "first  and  second  laws  of
thermodynamics"--all those "laws" which constrain our possi-
bilities in other contexts--no longer bind us!   Now  that's
anarchy!
 
     Or  consider  another possibility:  Suppose this hungry
Eskimo never learned  to  fish  because  the  ruler  of  his
nation-state    had  decreed fishing illegal.   Because fish
contain dangerous tiny bones, and sometimes sharp spines, he
tells us, the state has decreed that their  consumption--and
even  their  possession--are  too  hazardous to the people's
health to be permitted . . . even by knowledgeable,  willing
adults.   Perhaps it is because citizens' bodies are thought
to be government property, and therefore it is the  function
of the state to punish those who improperly care for govern-
ment  property.    Or perhaps it is because the state gener-
ously extends to competent adults the "benefits" it provides
to children and to the mentally ill:  namely,  a  full-time,
all-pervasive supervisory conservatorship--so that they need
not  trouble  themselves  with making choices about behavior
thought physically risky or morally "naughty."  But, in  any
case,  you  stare stupefied, while your Eskimo informant re-
lates how this law is taken so seriously that  a  friend  of
his was recently imprisoned for years for the crime of "pos-
session of nine ounces of trout with intent to distribute."
 
     Now  you  may  conclude  that  a society so grotesquely
oppressive as to enforce a law of this  type  is  simply  an
affront to the dignity of all human beings.  You may go far-
ther  and  decide to commit some portion of your discretion-
ary, recreational time specifically to the task of thwarting
this tyrant's goal.  (Your rationale may be "altruistic"  in
the   sense   of  wanting  to  liberate  the  oppressed,  or
"egoistic" in the sense of  proving  you  can  outsmart  the
oppressor--or  very likely some combination of these or per-
haps even other motives.)
 
     But, since you have zero desire to become a  martyr  to
your "cause," you're not about to mount a military campaign,
or  even try to run a boatload of fish through the blockade.
However, it is here that technology--and in  particular  in-
formation technology--can multiply your efficacy literally a
hundredfold.    I say "literally," because for a fraction of
the effort (and virtually none of  the  risk)  attendant  to
smuggling in a hundred fish, you can quite readily produce a
hundred  Xerox copies of fishing instructions.  (If the tar-
geted government, like present-day America, at least permits
open  discussion  of  topics  whose  implementation  is  re-
stricted,  then that should suffice.  But, if the government
attempts to suppress the flow of information as  well,  then
you will have to take a little more effort and perhaps write
your  fishing manual on a floppy disk encrypted according to
your mythical Eskimo's public-key parameters.  But as far as
increasing real-world access to fish you have  made  genuine
nonzero  headway--which  may  continue to snowball as others
re-disseminate the information you have provided.   And  you
have not had to waste any of your time trying to convert id-
eological  adversaries, or even trying to win over the unde-
cided.  Recall Harry Browne's dictum  from  "Freedom  in  an
Unfree World" that the success of any endeavor is in general
inversely proportional to the number of people whose persua-
sion is necessary to its fulfilment.
 
     If  you  look  at  history, you cannot deny that it has
been dramatically shaped by men with names like  Washington,
Lincoln,  .  .  .  Nixon  .  . . Marcos . . . Duvalier . . .
Khadaffi . . .  and their ilk.  But it has also been  shaped
by  people with names like Edison, Curie, Marconi, Tesla and
Wozniak.  And this latter shaping has been at least as  per-
vasive, and not nearly so bloody.
 
     And  that's  where  I'm  trying  to  take The LiberTech
Project.  Rather than beseeching the state to please not en-
slave, plunder or constrain us, I propose a libertarian net-
work spreading  the  technologies  by  which  we  may  seize
freedom for ourselves.
 
     But here we must be a bit careful.  While it is not (at
present)  illegal  to  encrypt  information  when government
wants to spy on you, there is no guarantee of what  the  fu-
ture  may hold.  There have been bills introduced, for exam-
ple, which would have made it a crime  to  wear  body  armor
when government wants to shoot you.  That is, if you were to
commit certain crimes while wearing a Kevlar vest, then that
fact  would  constitute a separate federal crime of its own.
This law to my knowledge has not passed . . . yet . . .  but
it does indicate how government thinks.
 
     Other  technological  applications,  however, do indeed
pose legal risks.  We recognize, for  example,  that  anyone
who  helped a pre-Civil War slave escape on the "underground
railroad" was making a clearly illegal use of technology--as
the sovereign government of the United States of America  at
that time found the buying and selling of human beings quite
as  acceptable  as  the buying and selling of cattle.  Simi-
larly, during Prohibition, anyone who used  his  bathtub  to
ferment  yeast and sugar into the illegal psychoactive drug,
alcohol--the controlled substance, wine--was using  technol-
ogy  in a way that could get him shot dead by federal agents
for his "crime"--unfortunately not to be  restored  to  life
when  Congress  reversed itself and re-permitted use of this
drug.
 
     So . . . to quote a former President,  un-indicted  co-
conspirator  and pardoned felon . . . "Let me make one thing
perfectly clear:"  The LiberTech Project does not  advocate,
participate  in, or conspire in the violation of any law--no
matter how oppressive,  unconstitutional  or  simply  stupid
such  law may be.  It does engage in description (for educa-
tional and informational  purposes  only)  of  technological
processes,  and some of these processes (like flying a plane
or manufacturing a firearm) may well require appropriate li-
censing to perform legally.    Fortunately,  no  license  is
needed  for  the  distribution or receipt of information it-
self.
 
     So, the next time you look at the political  scene  and
despair,  thinking,  "Well,  if 51% of the nation and 51% of
this State, and 51% of this city have  to  turn  Libertarian
before  I'll  be  free,  then  somebody might as well cut my
goddamn throat now, and put me out of my  misery"--recognize
that  such  is not the case.  There exist ways to make your-
self free.
 
     If you wish to explore such techniques via the Project,
you are welcome to give me your name and address--or a  fake
name  and  mail  drop, for that matter--and you'll go on the
mailing list for my erratically-published newsletter.    Any
friends  or acquaintances whom you think would be interested
are welcome as well.  I'm not even asking for stamped  self-
addressed envelopes, since my printer can handle mailing la-
bels and actual postage costs are down in the noise compared
with  the  other  efforts  in getting an issue out.   If you
should have an idea to share, or even a  useful  product  to
plug,  I'll be glad to have you write it up for publication.
Even if you want to be the proverbial "free rider" and  just
benefit  from  what others contribute--you're still welcome:
Everything will be public domain; feel free to  copy  it  or
give it away (or sell it, for that matter, 'cause if you can
get  money  for  it while I'm taking full-page ads trying to
give it away, you're certainly entitled to  your  capitalist
profit . . .)  Anyway, every application of these principles
should make the world just a little freer, and I'm certainly
willing to underwrite that, at least for the forseeable  fu-
ture.
 
     I  will leave you with one final thought:  If you don't
learn how to beat your plowshares into  swords  before  they
outlaw  swords,  then you sure as HELL ought to learn before
they outlaw plowshares too.
 
                                       --Chuck Hammill
 
                                 THE LIBERTECH PROJECT
                                 3194 Queensbury Drive
                               Los Angeles, California
                                                 90064
                                          310-836-4157

[The above LiberTech address was updated June 1992, with the
 permission of Chuck Hammill, by:

Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMIX: RWHITAKER
Board member, Extropy Institute (ExI)
[.sig revised 11 September 1992    ///    Send mail to eternity node]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no
pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI
lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR
tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j
by51az4=
=LOCL
-----END PGP PUBLIC KEY BLOCK-----





That's it from here.

Over.
Ono-Sendai Corporation





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughesNsoda.berkeley.edu>
Date: Mon, 21 Sep 92 22:47:51 PDT
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9209220543.AA25094@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Welcome to the cypherpunks mailing list.

We have a real mailing list now, and not just a mail alias on my
account.  Thanks to John Gilmore for space on hoptoad and Hugh Daniel
for setting things up.

Mail to the list members at

	cypherpunks@toad.com

Request additions or deletions, talk to the list maintainer (me, Eric
Hughes) at

	cypherpunks-request@toad.com

Tell your friends about the list and have them join if they wish, and
have them do the same, but please do not post the list address yet.
We'd like to have a core group working before we advertise to avoid
diffusion of interest at the outset.

----------------------

ANNOUNCEMENT

Second Meeting -- October 10, 1992


The second meeting will be held at the new Cygnus offices.  Exact
address and directions to follow.

We do not have an exact agenda yet, but one should be arriving in the
next few days.  Please mark you calendars now and start telling your
friends.

For this meeting and until further announced, we are using a
transitive trust system for invitations.  Invite anybody you want and
let them invite anybody they want and so on.

The crypto-anarchy game we tried out at the first meeting was as good
a success as we could have hoped for from an untested idea.  The game
seems useful and fun enough to warrant continued play and play
testing, so we'll be playing again at this and future meetings.  

We observed several interesting emergent behaviors in the first
session, including resellers and reputation behaviors.  We'll play a
two hour session this time and discuss it afterwards.


Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Tue, 22 Sep 92 12:17:43 PDT
To: cypherpunks@toad.com
Subject: Radio program on wiretaps and encryption:  Wednesday at noon
Message-ID: <9209221917.AA02319@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Newsgroups: sci.crypt,alt.privacy,alt.activism
Subject: Radio program on wiretaps and encryption:  Wednesday at noon
Message-Id: <35449@hoptoad.uucp>
Date: 22 Sep 92 19:15:19 GMT

The Telecommunications Radio Project at KPFA is producing a series of
thirteen hour-long radio programs on issues in communications.  The
first program is on the FBI's `Digital Telephony' e-z-wiretap proposal
and the politics of encryption.

The first half-hour will be an introduction and a panel discussion,
featuring Jim Bidzos of RSA Data Security; Jim Kalstrom, head of
investigative technology for the FBI; and me, representing the
Electronic Frontier Foundation.  You can phone in questions and comments
in the second half of the show.  The call-in number is:

	+1 800 464 5732

This program will be broadcast live on Wed, September 23, at noon, on
these California stations:

	KPFA	Berkeley
	KPFK	Los Angeles
	KHSU	Arcata

These other stations will be picking up the broadcast, 
and probably transmitting it at a later time.  Phone the station to find
out when it's scheduled.

KMUD	Redway, California	KCBL	Sacramento, California
KPBS	San Diego, California	WMNF	Tampa, Florida
KSUI	Iowa City, Iowa		KSAI	Minneapolis, Minnesota
KSMU	Springfield, Missouri	WCPN	Cleveland, Ohio
WYSO	Yellow Springs, Ohio	WBAI	New York, New York
WXXI	Rochester, New York	WEOS	Geneva, New York
KRCL	Salt Lake City, Utah	KPBX	Spokane, Washington
KUOW	Seattle, Washington

If you are not with in reach of a station that is broadcasting the
Communications Revolution, please call your local station and pitch it
to the program director.  Have them call the Telecommincations Radio
Project at KPFA, at +1 510 848 6767 x263 or x264.

Future shows (Wednesdays at noon) will cover isses like how the concept
of libraries is changing; what information is availible to (and held
back from) the public; and electronic democracy where the voters can
feed back directly to goverment agencies or change the outcome of an
election via computer networks.

Please tune in, and phone in good questions.  See you in the airwaves!
-- 
John Gilmore                gnu@toad.com  --  gnu@cygnus.com  --  gnu@eff.org
"It isn't given to us to know those rare moments when people
 are wide open and the lightest touch can wither or heal."




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 23 Sep 92 13:25:19 PDT
To: cypherpunks@toad.com
Subject: KPFA interview went well
Message-ID: <9209232007.AA03117@netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


This is my first test of this list...hope it works...and a brief
opinion on the KPFA (etc.) interview with our own John Gilmore,
representing the EFF, Jim Bidzos, of RSA Data Security, and Jim
Kellstrom (sp?) of the FBI.

I made a tape of it and can bring it to the 10/10/92 crypto meeting.

John did an excellent job of raising the constitutional issues, while
the FBI guy basically said "Trust us." Jim Bidzos of RSA Data Security
didn't say much, as the thrust of the discussion was more on
wiretapping and the proposed Digital Telephony bill, with not much of
substance said about RSA and public key cryptography.

I waited on the 1-800-464-5732 line to ask about the status of use of
encryption, especially with RSA and RSA-like systems, but the show ran
out of time before I could get on.

This series seems timely. Every Wednesday at noon on KPFA. Check your
local listings and the announcement list John sent out a few days ago.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | RSA MailSafe Public Key: by arrangement






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Wed, 23 Sep 92 17:28:41 PDT
To: cypherpunks@toad.com
Subject: New! Eric's Cheap Remailing Service.  Free!
Message-ID: <9209240027.AA27179@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Pssst.

You don't know where you heard this.  There's a new service available,
and it's free.

If you send mail to 

	hughes@soda.berkeley.edu

with a header line of the form

	Request-Remailing-To: <addressee>

then the software will strip off all the header lines (except the
Subject: line) and remail it to the addressee of your choice.

But there's this rumor that he's saving all the message that pass
through.  Damn.

Mr. Crypto




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Mark Pesce <osendai@well.sf.ca.us>
Date: Thu, 24 Sep 92 00:45:30 PDT
To: cypherpunks@toad.com
Subject: Interesting post to alt.cyberpunk.tech
Message-ID: <199209240744.AA20447@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



Thought ya'll might be interested in this....





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: cliff_stoll@harvard.edu
Date: Wed, 23 Sep 92 22:53:12 PDT
To: hughes@soda.berkeley.edu
Subject: Fake Mail
Message-ID: <9209240552.AA04259@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


Pssst!
 
I have a nice fake mail program that interfaces with emacs.
I'll send it along to anyone who wants it.
 
PS: Have you seen my latest chocolate chip cookie recipe?
    Too bad about Martha.  Maybe people like me are wed
    to science...and great cookies.
 
ADFGVX




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pozar@kumr.lns.com (Tim Pozar)
Date: Thu, 24 Sep 92 10:28:07 PDT
To: tcmay@netcom.com (Timothy C. May)
Subject: Re: KPFA interview went well
In-Reply-To: <9209232007.AA03117@netcom.com>
Message-ID: <m0mXwxx-00029lC@kumr.lns.com>
MIME-Version: 1.0
Content-Type: text/plain


Timothy C. May wrote:
> This is my first test of this list...hope it works...and a brief
> opinion on the KPFA (etc.) interview with our own John Gilmore,
> representing the EFF, Jim Bidzos, of RSA Data Security, and Jim
> Kellstrom (sp?) of the FBI.
> [...] 

   Thanks for your input.  If anyone else wants to feed back to the
program, they can send me email and I will pass it along to the producers.
I am also the technical consultant to the show, so your mail will not be
falling on deft ears...

               Tim
-- 
Internet: pozar@kumr.lns.com               FidoNet:  Tim Pozar @ 1:125/555
UUCP:     ...!uunet!kumr.lns.com!pozar
Snail:    Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
Voice:    +1 415 788 2022




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 24 Sep 92 11:10:30 PDT
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9209241809.AA23637@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


How to Make an Automated Remailer in Your Copious Spare Time with Easy
to Find and Inexpensive Software Tools You May Have Lying Around.

<reprinted from Popular Cryptography, September 1992. Used with permission>


The basic remailer illustrates how to hook in automated software
processing into the Unix mail system.  Here are the basic elements.

1. .forward
2. slocal and .maildelivery
3. remail.perl
4. /usr/lib/sendmail

--------------------------------------------
1. .forward

Unix mail provides a way to have accounts on many different machines
but to receive all your mail in one place.  That facility is the
.forward file, which resides in the home directory.  The file is one
line long and contains the email address to which the mail will be
forwarded.

But the .forward file has another mode of operation.  If the string
begins with the pipe character '|', the mail will be piped through the
program listed.  Enclose the string with double quotes if you need
spaces included.  Here is my .forward file:

"| /usr/local/lib/mh/slocal -user hughes"

Thus all my mail gets processed by the slocal program, described next.

I don't know where the man page for .forward is.  Perhaps someone
could provide a reference.

---------

2. slocal and .maildelivery

The software system MH contains a bunch of useful tools for handling
mail, only one of which we need.  For details on MH, do 'man mh'.

MH has a nice little mail hook processor called slocal.  Its docs can
be found by 'man mhook'.  slocal can conditionally perform operations
on mail messages and consider them either delivered or not.  It allows
multiple operations on individual mail messages.

slocal reads the file .maildelivery when it starts up for
instructions. Here is my .maildelivery file:

#
# field			pattern	action/	string 
#				result	(quote included spaces)
#
Request-Remailing-To	""	pipe R	"perl remail.perl" 
Request-Remailing-To	""	file R	archive.remailer

The various pieces of the .maildelivery file are fully documented in
the man page.  I'll just explain what mine does.  Each line describes
one operation to be performed on each incoming mail message.  Fields
are separated by whitespace, so if you need to include spaces, use
quotes.

The first field, labelled field, is the mail header field to look for.
slocal can selectively process on any header line.  If the header line
does not exist, then the mail does not match this line and no
operation is performed.  If the header line does exist, processing
continues.

The second field, pattern, is a text string to match with the contents
of that header line, i.e. with everything after the colon.  In my
case, I put the empty string in, which matches everything.  You need
the pair of quotes to have a placeholder for the field contents.

The next field, action, tells what to do with the message.  'pipe'
sends the message to the standard input of the named program.  'file'
appends the message to an archive or log file.  A useful pipe command
for testing is "tee foo", which makes a copy of the message in file
foo, but does not append, so that you get an exact copy of what slocal
is going to pass to your pipe.  This allows testing of the pipe
program without sending yourself mail all the time.

The next field, result, tells what to do with the message after
processing.  I am currently using R for Regardless to indicate that
this action should always be performed no matter what.  The code R
indicates that the mail should be considered not delivered after
processing; thus slocal writes the mail back into my local spool and I
see it as normal.  Later, after I'm sick of looking at all the
forwarded mail, I'll change this code to A, meaning if the processing
succeeds, then the mail is considered delivered.  The archive file
will always remain R.

The last field, string, is the parameter to the action.  It is a file
name or program.  Use quotes to include spaces.  The name of my mail
processor is "perl remail.perl", which is to run the perl script
remail.perl on the mail.

The .maildelivery file is also the place to put encryption hooks to
automatically decrypt the bodies of messages.  More on that in a
future version.

---------

3. remail.perl

Perl is a wonderful language for doing all sorts of useful work like
processing mail headers.  Do 'man perl' for details, or get the
O'Reilly book and really learn how to use it.

The perl script, in summary, strips off the mail headers, saving the
Subject: line, rewrites a new header, and appends the body of the
previous message.  Here is the script:

--------- cut here ---------
while (<>) {
	last if /^$/ ;
	$subject = $_ if /^Subject:/ ;
	if (/^Request-Remailing-To:/) {
		chop ;
		s/^.*:// ;
		$addressee = $_ ;
	}
}

#open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ;
open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ;
select( OUTPUT ) ;

print "To:" . $addressee . "\n" ;
print "From: nobody\n" ;
print $subject ;
print "Remailed-By: Eric Hughes <hughes@soda.berkeley.edu>\n" ;
print "\n" ;

while (<>) {
} continue {
	print ;
}
--------- cut here ---------

Here is a summary of the operation.  To really understand this, you'll
have to learn perl.

The while loop processes standard input.  'last' terminates the loop
as soon as a blank line is seen.  A blank line separates the header
from the body.  The subject line, if seen, sets the subject variable
to the whole subject line.  The Request- header line has its final
newline removed, the contents up to the colon substituted into
nonexistence, and saves the rest in the addressee variable.

Next the pipe to sendmail is opened and its output is selected so that
all print commands will go to the pipe.  There is a comment for a
different output channel to the file foo which can be commented in for
testing.

Next the remailed header is constructed out of print statements.

Lastly the rest of the standard input is passed through unmodified to
the output channel.  The while loop terminates when there is no more
input.

---------

4. sendmail

sendmail is the backend mailer; it expects complete mail messages and
does not usually generate any line itself except for the first "From"
(with no colon) line.  Any header you construct will thus get passed
through mostly unmodified.  Hence you can put in any "From:" line you
want and any other header info, such as my "Remailed-By:" line.

sendmail expects the name of the addressee on its command line,
otherwise it puts an "Apparently-To:" line in the header.

Any mail processor which remails should probably go through sendmail,
although it would also be possible to talk to an SMTP port directly,
were you so motivated.  MH also has some remailing programs; see 'man
mhook'.

---------

A few words for tinkerers.

-- You can always send mail to yourself.  Especially after you've done
one kind of mail processing and want to pass the mail through the
filters again.

-- When getting started, create an empty .maildelivery file first and
then get your .forward file working.  Test it by sending messages to
yourself.  If you're not getting them, they are going into the bit
bucket.  All your other mail will as well, in this case, so if you
can't afford to lose mail, do it right the first time or work on a
spare account.  

-- Any mail slocal does not process will get delivered as normal.
Running a remailer will not interfere with your other work.

-- Remember to use quote marks.

-- You don't need to be a sysadmin to run this kind of remailer.
There is nothing, however, to prevent a sysadmin from running this
sofware under an alias.  The sysadmin is also a 'trusted user' to
sendmail and can get rid of pesky "From"-no-colon lines.

-- Perl has a random function which could be used to automatically
choose various "From:" lines from a database.  Remember to include
yeltsy@kremvax.rus.

-- postnews or inews could be substituted for sendmail.  Different
header lines would have to be created.  Such a service could run in
parallel with a remailer.  You too can now repost to alt.sex.bondage!


Enjoy.  And watch for interesting improvements like encryption.


Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 24 Sep 92 11:13:21 PDT
To: cypherpunks@toad.com
Subject: The aural Tim Pozar
In-Reply-To: <m0mXwxx-00029lC@kumr.lns.com>
Message-ID: <9209241811.AA23823@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Tim Pozar writes:

>I am also the technical consultant to the show, so your mail will not be
>falling on deft ears...

Just for the record, Tim's _are_ deft, but they are _not_ deaf.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pozar@kumr.lns.com (Tim Pozar)
Date: Thu, 24 Sep 92 16:42:21 PDT
To: hughes@soda.berkeley.edu (Eric Hughes)
Subject: Re: The aural Tim Pozar
In-Reply-To: <9209241811.AA23823@soda.berkeley.edu>
Message-ID: <m0mY2oA-00029tC@kumr.lns.com>
MIME-Version: 1.0
Content-Type: text/plain


Eric Hughes wrote:
> Tim Pozar writes:
> 
> >I am also the technical consultant to the show, so your mail will not be
> >falling on deft ears...
> 
> Just for the record, Tim's _are_ deft, but they are _not_ deaf.

   Thanks... :-)

                     Tim

-- 
Internet: pozar@kumr.lns.com               FidoNet:  Tim Pozar @ 1:125/555
UUCP:     ...!uunet!kumr.lns.com!pozar
Snail:    Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
Voice:    +1 415 788 2022




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Thu, 24 Sep 92 19:32:44 PDT
To: cypherpunks@toad.com
Subject: through mr. crypto
Message-ID: <9209250231.AA10851@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


** I am also the technical consultant to the show, so your mail will not be
** falling on deft ears...

Awwww.... it wasn't that badly engineered.

sho3t




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Mailer-Daemon@atdt.org (Mail Delivery Subsystem)
Date: Thu, 24 Sep 92 16:49:37 PDT
To: cypherpunks@toad.com
Subject: Returned mail: Unable to deliver mail
Message-ID: <9209242349.AB06629@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


   ----- Transcript of session follows -----
554 cypherpunks@toad.com... Recipient names must be specified

   ----- Unsent message follows -----
Return-Path: <cypherpunks@toad.com>
Received: by atdt.org (5.61+++/JLK-atdt)
	id AA06629; Thu, 24 Sep 92 19:49:05 -0400
Date: Thu, 24 Sep 92 19:49:05 -0400
From: cypherpunks@toad.com
Message-Id: <9209242349.AA06629@atdt.org>
To: cypherpunks@toad.com
Subject: Information Brokers

____________________________________________________________________________


SYDNEY MORNING HERALD
August 13 1992


HUGE TRADE IN PERSONAL FILES
By MALCOLM BROWN


Westpac, National Australia Bank, NRMA Insurance Ltd, Custom Credit
and
Citicorp are some of the big names in a damning report by the ICAC
Assistant Commissioner, Mr Adrian Roden, QC, on the unauthorised
release of
confidential government information.


Mr Roden found that there was a multi-million-dollar trade in such
information which involved public servants, including police, and
private
inquiry agents.
""Information, from a variety of State and Commonwealth government
sources
and the private sector has been freely and regularly sold and
exchanged for
many years," he said. "NSW public officials have been heavily
involved."


Mr Roden heard 446 witnesses in public and private hearings over 168
days
before compiling his 1,300-page report.


Even so, he said, it was necessary to be selective; thousands of
private
and commercial inquiry agents had not examined.


Mr Roden found that more than 250 people had participated in the
illicit
trade or had contributed to it.

OOf these, 155 had engaged in corrupt conduct. A further 101 had
engaged in
conduct which allowed, encouraged or caused the occurrence of corrupt
conduct.


Many are NSW and Commonwealth public servants who sold information
collected by the agencies where they work, including the Roads and
Traffic
Authority (RTA), police force, Telecom and Sydney County Council.


The Attorney-General, Mr Hannaford, announced that the Director of
Public
Prosecutions had set up a task force to consider laying charges
against
more than 100 people named in the report.

HHe said many of the public servants named could expect to lose their
jobs
and that the heads of all the government departments involved had been
told
to examine the report and take action against those involved.


The Assistant Police Commissioner, Mr Col Cole, confirmed yesterday
that
five police officers had been suspended and announced that three task
forces had been set up and computer security upgraded.


Mr Hannaford foreshadowed the introduction of privacy legislation to
make
the unauthorised use of confidential information a criminal offence.


The major banks said that they could not condone what their staff had
done
but said the staff had believed that they were acting in the best
interests
of their employers and the community.


None of the banks was planning to sack staff found to be corrupt
although
several said the staff had been counselled or "educated".

MMr Roden said the trade involved banks, insurance companies and other
financial institutions which had provided "a ready market".


The link was provided by private and commercial inquiry agents. With
some
banks, codes had been used to conceal the nature of the transactions.


"As they have gone about their corrupt trade, commercial interest has
prevailed over commercial ethics, greed ha~ prevailed over public
duty;
laws and regulations designed to protect confidentiality have been
ignored," Mr Roden said.


"Frequently the client, generally an insurance company, bank or other
financial institution, ordered the information from the agent with a
full
appreciation of how it was to be obtained.

""The evidence disclosed that in the collection and recovery
departments of
a number of those institutions, it has long been standard practice to
use
confidential government information . . . as a means of locating
debtors."


Some finance and insurance companies had directed agents to keep all
references to the trade off invoices and reports.


"Some even directed that the agents falsely state the source of the
information in their reports," Mr Roden said.


"Some solicitors in private practice have sought and purchased
confidential
government information in circumstances in which they must have known
that
it could not have been properly obtained."


Mr Kevin Rindfleish, an unlicensed private inquiry agent, had sold
Department of Motor Transport/Roads and Traffic Authority and social
security information "on a large scale". His principal client had been
the
ANZ Bank.
AA private investigator, Mr Terence John Hancock, and his company, All
Cities Investigations Pty Ltd, had sold confidential government
information
to the National Australia Bank and Westpac on a regular basis.


 Two employees of the NAB had used prior contacts to provide the bank
with
access to RTA, social security, Australia Post and immigration
information.
Between them, the employees also provided silent numbers and
information on
electricity consumers.


The Advance Bank had "over a period of years" obtained information
improperly released from the RTA, the Department of Social Security
and the
Department of Immigration. The practice was "known and approved at
least to
senior management level".


New Zealand Insurance and Manufacturers Mutual had bought confidential
government information from private investigators.


NRMA Insurance Ltd and the Government Insurance Office were "found to
have
participated as freely in the illicit trade in confidential government
information as their more commercially orientated competitors".


"Evidence relating to NRMA Insurance Ltd established not only that it
purchased confidential government information through private
investigators, but also that investigators were required to obtain
relevant
government information by unauthorised means if they were to retain
the
company's work."
EEsanda Finance Corporation Ltd had bought confidential information
over at
least 23 years. Custom Credit Corporation Ltd which had engaged in the
illicit trade over "many years", had maintained false records to
conceal
how it obtained information.


Alston de Zilwa, former underwriter and operations manager of Citicorp
Ltd
and later, Toyota Finance Australia Limited's credit operations
manager,
had established for each of the two companies a system for obtaining
confidential information.


The companies would seek information directly from employees of the
DMA and
RTA and pay a private inquiry agent, Mr Kevin Robinson, who would
"launder"
it, then invoice the companies for the corresponding sum.


Mr Roden said that hundreds of thousands of dollars had changed hands
in
the trade uncovered. One agent had estimated that he had paid $40,000
to
$50,000 a year for Social Security information alone.


Another had said he received $100,000 over two years for government
information.
YYet another had, according to records, charged a bank $186,000 for
"inquiry
services" over a period of 18 months.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Judith Milhon <stjude@well.sf.ca.us>
Date: Fri, 25 Sep 92 03:02:38 PDT
To: cypherpunks@toad.com
Subject: secretions
Message-ID: <199209251001.AA16909@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain




"The alternative to mutual trust, which is indeed a risky gamble, is the
security of the police state."
                -- Alan Watts
   
This text may be published in MONDO2000 as my regular column, Irresponsible
Journalism. Eric Hughes suggested the coda with the toad address, adding
that it would be amusing to have it almost completely blotted by magic
marker, as if inadequately censored.

I don't want to be the venom in this toad. <I'd like to be one of the
jewels
it wears in its head -- I can't quote that precisely, but it's something
like, "the venomous toad, which yet in its head wears a precious
jewel"...>
the idea is to draw in other useful minds. we can assume the WRONG PEOPLE
already know the address.

lady ada won't apologize for the gonzo wrapping for the ideas; she is
concerned only that they be correct and clearly stated. clarifications,
expansions, corrections are welcome. also abuse and threats, for that
matter... any feedback, please feed me...


THE CYPHERPUNK MOVEMENT
by St. Jude

I don't face-to-face all that much.  And I don't like clubs.  I was in the
Black Hole for a reason: The Screamin' Memes were in town for one night
only -- Thursday, of course.  Thursday's the night, now that the weekend
has annexed Fri. and Mon.  I was lurking in the back, hoping not to see
anybody, when the Jones brothers staked me out.  Damn.  They are deep into
the street drugs.  Keeping up with the Joneses is nigh impossible; their
most trivial chitchat is an exercise in decryption.  Eddy -- or maybe he
was being Ellis that night -- was implying something about somebody when my
right foot detonated down to its steel toe.  I looked up -- way up -- to a
face that wasn't there at all.  Just a dome of black cloth, with goggles.
Three-eyed goggles.  Ah: a Chador.  I'd heard of that.  I screamed: "You
stomped my foot FLAT!"
   "Sorry."  "Are you okay?"  "Oh maaaang."  Many overlapping voices, all
of them synthesized, blurted from above.  Out of two tiny speakers hanging
like earrings off a basketweave headband like a cop's belt.  The head
bowed, bringing it almost within biting range.
   "Gah.  Ow.  Ooo."  Pretending to be demented with pain, I lurched deep
into the Chador.  But I was cool: I was rootling in there for clues.  Ha!
Male pheromones.  Hardish male torso.  I was jostling this lumpy equipment
hanging off him, trying to get a good feel of it without alerting him.  Nuh
uh: _I_ meant electronics... what did _you_ think?  Okay: I had some data
to work with.  Male with gadgets.  Quelle surprise.
	"What the hell have you got on your feet?  HORSESHOES?"
	A voice like rushing water: "Kothurni."  The Chador shifted a
little...
and under his full black skirts I saw them: big weighted club-foot boots
with concealed lifts, to disguise the wearer's height.  Wicked. 
   The pain and the espionage cleared my head.  I was ready to deal.
   "So you're protecting your meat identity, right?"
   The Chador seemed to teeter a little.  It goggled down at me as if I
were a smear on a slide.  Its third-eye goggle was a lens.  Check.  Out of
the ambient murk loomed another Chador.  Exactly the same height.  Right.
   "How come you guys are in full drag?"
   "We're here for a... uh... party."  The voice from the other Chador was
a flanged saxophone, but I could swear it had a Texas accent.
   "Rubbish.  You're having a cell meeting, right?  "
   The near Chador, the one I had groped, seemed to teeter again.  What
sounded like a tape player on fast-forward came faintly from its interior.
An earphone? 
   The saxophone honked:  "If I said I even understood what you meant, what
kind of a chump would that make me?" 
   "I could hazard a guess.  I think you're cryptoanarchists -- what I'd
call cypherpunks!"
   My Chador cracked up.  I could tell.  The farther one seemed to stiffen;
I think it was giving me a hate stare.  Hard to manage behind the whole 9
yards o' cloth. 
   "Is that clever or what?  I'm onto you like psilocybe on cowshit, dudes.
You want to take over the world.  Haha hahaha haaaaa."
   Both of them rocked back a little.  I went in after them. "You want to
talk encryption schemes?  Let's talk cryptic.  Tales from the cryp'ed.  But
make it fast: The Memes are comin' on."  Oh, I was bluffing.  I don't know
much about cryptography.  I was just 'tuding them from tech envy.  Damn:
Chadors.  And me without the first widget.
   From the far guy came a cello, very suave: "The world has already been
taken over.  You may have noticed this.  We're just trying to get some of
it back."  And the accent was -- Dutch?
   Bob's yr uncle.  Gotcha.  I hadn't been certain.  Maybe chadors were now
trendy club gear -- what do I know?  "Hey -- that cello's another guy?  How
many you PACKIN' in there?"
   Out of my Chador a sawtooth rasped:  "Variable.  People are ringing in
and out."
   "You're on line?"
   "This is a bridge.  International."  Sawtooth again.
   The cello resumed, an annoyed cello:  "We don't believe in takeovers.
In fact, we are working to make things UNTAKEOVERABLE."
   A theremin quivered, "And to make the world safe for anarchy.  _We want
the air-waves, baby_."  It snickered across many frequencies.
   The Tejana saxophone chuckled, (and an eerie treat that was, too):
"Problem is, how to guarantee privacy for pseudonyms.  So you can have a
pseudonymous economy."
   A toad croaked: "So, full-RSA encrypted EVERYTHING.  No back doors.
Secure digital money.  Swiss bank accounts for the millions."
   The theremin: "A global monetary system that makes governments obsolete.
Down come the governments.  Goodbye the feds."  It sang, whoopingly: "BYE
BYE, LAWWww."  Horrible broad-band snickering.
   The toad croaked: "Er... yes.  Real freedom of speech, too.
Libertech!"
   The Dutch cello was all business: "Okay, what does it take?  You need
real-time protocols to prove you own your pseudonym.  And your pseudonyms
have online reputations, via people you've done biz with -- like a
distributed credit rating system.  With maybe designated angels -- Fair
Witnesses."
   I was charmed.  "And you wear the chador when you face-to-face somebody
who knows your handle!" 
   The theremin wheeped: "Actually, unmasking your real identity could be
the ultimate collateral -- your killable, _torturable_ body.  Even without
kids, you've got a hostage to fortune -- your own meat."
   I was reeling.  "Oh yas yas.  As Dylan said: 'They asked me for some
collateral/ and I pulled down my pants'."
   Orchestral chuckles rained down on me.  Was I an international hit?
   But at that exact moment The Memes hit the stage.  The crowd did a 9.1
Richter lurch and the other Chador pitched onto my LEFT toe, maybe denting
the steel.
   "AAIEEeeee.  That's great COVERT GEAR you got there, guys.  You couldn't
sneak up on Helen Keller in a HAILSTORM."  I was trying to spin down.  "And
dudes -- this is not the neighborhood for flashing the hardware.  Getting
rolled by winos is pretty LOW TECH."
   A spike-knuckled glove slithered out of the farther guy, clutching what
looked, in the near-dark, like an electric razor.  "_Gonna menace 'em with
a clean shave_?"
   The sax: "Stunner.  Bottom of the line.  But."  A hot line of pure
energy cracked across its little trodes.  Of course.
   Rushing water: "See ya."  And they did a fade into the smoke.

   The Screamin' Memes were worthless.  To hell with clubs.  To hell with
lots o' things, maybe.  I am now sensing my roots, mahn; dey who are my
bredren.  Nerds.  
   Nerds as mainstreamed by the grainy but still fetching Robt Redford in
Sneakers...  Nerds who will have their revenge at last, by making the
online realer than our current regrettable reality...  No, I'm not quite
delusional.  I've heard the cypherpunks are already distributing their
encrypted email software, which is quick and slick.  I might even join the
revolution, which is, heh, already in progress.  
   Yeah.  Why not?  Give me libertech or give me... _DES_? 

---------------------------------------------------------------------------
-------------------------
St. Jude, aka Lady Ada Lovelace, wrote "The Spook in the Machine" for MONDO
#1, describing the enforcement of DES, the Data Encryption Scam with the
handy backdoor.  She can be reached online as stjude@well.sf.ca.us.  Note:
a definitely false rumor is now circulating that the revolutionists can be
contacted via cypherpunks@toad.com.

--------------------------------------------------------------------------

feed me?

>jude<




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 25 Sep 92 11:37:12 PDT
To: cypherpunks@toad.com
Subject: the hopping remailer is done
Message-ID: <9209251835.AA00599@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



The hopping remailer is finished.  I wrote it this morning.

The change to make a hopping remailer is very easy.  Here's the new
perl script:

--------- cut here ---------
while (<>) {
	last if /^$/ ;
	$subject = $_ if /^Subject:/ ;
	if (/^Request-Remailing-To:/) {
		chop ;
		s/^.*:// ;
		$addressee = $_ ;
	}
}

#open( OUTPUT, ">foo" ) || die "Cannot open 'foo'." ;
open( OUTPUT, "| /usr/lib/sendmail " . $addressee ) ;
select( OUTPUT ) ;

print "To:" . $addressee . "\n" ;
print "From: nobody\n" ;
print $subject ;
print "Remailed-By: Eric Hughes <hughes@soda.berkeley.edu>\n" ;

#
# check to see if there are header lines in the body to collapse 
#   into the full header.
#

if ( $_ = <> ) {
	if (/^##$/) {
		# do nothing if the pasting token appears
		# the rest of the body will be directly appended
		# this allows for extra header lines to be added
	} else {
		# normal line
		print "\n" ;
		print $_ ;
	}
} else {
	# empty body
	exit ;
}

while (<>) {
} continue {
	print ;
}
--------- cut here ---------

Short explanation.  The 'print "\n" ;' line was moved inside the new
if statement.  The if statement reads a line of the body and stops the
script if there is no body.  The line read is tested to see if it
contains the two characters "##" alone on the line.  "##" is the ANSI
C token pasting operator.  If there is no pasting, a blank line is
printed to mark the end of the header and the first line of the body
is printed.  If there is pasting, then the conditional does nothing,
which has the effect that the body is appended directly onto the end
of the header, allowing you to add more header lines after the header
is rewritten.


Here is a sample message that I sent myself after the new script was
installed:

--------- cut here ---------
To: hughes
Subject: multiple hops
Request-Remailing-To: hughes

##
X-Hop: 1
Request-Remailing-To: hughes

##
X-Hop: 2
Request-Remailing-To: hughes

##
X-Hop: 3

This is a test message of multiple hops.

Eric
--------- cut here ---------


I received four pieces of mail after sending this to myself.  The
first was the actual letter, which is still delivering normally and
not being filtered.  The next two were the first and second
remailings; they had X-Hop: 1 and 2.  The last message was the final
one, had X-Hop: 3 in its header and was delivered normally.

At each stage, the header got rewritten and a new
Request-Remailing-To: line inserted.  When that mail got delivered, it
was again rewritten, with a new remailing request.  This process is
extensible up to the 50K or so practical limitatation on mail size.

Note that this system is not at all secure by itself.  But if each
message body were encrypted first, and the message first decrypted
before the header re-write took place, the routing instructions as a
whole would be hidden from prying eyes.

That's the next project.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Mark Pesce <osendai@well.sf.ca.us>
Date: Fri, 25 Sep 92 16:27:24 PDT
To: cypherpunks@toad.com
Subject: Pointing out the obvious....
Message-ID: <199209252326.AA19540@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



Hey, Kidz....


I don't mean to point out the obvious, but when you mention a certain
scheme for secure transfer (3 initials, you guess), or a certain organization
dedicated to keeping it from the public (3 initals, you guess again),
THEY READ IT.

OK?  Did I make my point?
If not, we're going to unsubscribe from this list like a bat out of hell.

Over,
OS Corp.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: not_root@nowhere.com
Date: Fri, 25 Sep 92 17:27:32 PDT
To: cypherpunks@toad.com
Subject: Hints
Message-ID: <9209260027.AA08573@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


Most internet traffic is archived (and later Grep'd) anyway.
If you're really that worried about it, then we should have
been speaking in Aramaic all this time, or using encrypted
e-mail (and I'm sure traffic which mentions the characters
"crypt" draws attention as well, and most of the msgs on this
mailing list have already violated that one.)  I'm interested
to see the PGP addition to the re-mailer.
 
-- Concerned, yet not overly unrealistic about it.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Fen Labalme" <fen@genmagic.com>
Date: Mon, 28 Sep 92 21:01:24 PDT
To: "Cypher Punks" <cypherpunks@toad.com>
Subject: SEIZING THE MEDIA- A NETWOR
Message-ID: <9209290409.AA25631@relay2.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


Mail*Link( Remote             SEIZING THE MEDIA: A NETWORKER CONGRESS

from PeaceNet ACTIV-L:

Date:         Sat, 26 Sep 1992 23:33:10 CDT
Sender: Activists Mailing List <ACTIV-L%MIZZOU1.BITNET@pucc.Princeton.EDU>
From: "(Rich Winkel)" <rich@pencil.cs.missouri.edu>
Subject:      PAX: SEIZING THE MEDIA: A NETWORKER CONGRESS
To: Multiple recipients of ACTIV-L <ACTIV-L%MIZZOU1.BITNET@pucc.Princeton.EDU>

/** gen.media: 141.0 **/
** Topic: SEIZING THE MEDIA: NETWORKER CONGR **
** Written  6:39 pm  Sep 25, 1992 by openmedia in cdp:gen.media **

                  SEIZING THE MEDIA:  A NETWORKER CONGRESS
               A weekend of activity to discuss, self-educate,
           and put into practice the creation of subversive media.

           1:30pm Saturday 24 October to 6pm Sunday 25 October 1992

             Media and resource exchange;  slides, fax, posters, 
	     pamphlets, computer files, ideas, proposals, tactics

            Practical action on billboard improvement and removal;
                           Big Art and postering

               E-mail and fax facility to receive material 
	    to be discussed and implemented during the weekend

                     Documentation to all participants

        Materials supplied:  photocopier reproduction/enlargement 
      	 and the streets of Oxford
       Bloomin Arts, Princes Street, Cowley Road, Oxford, OX4, U.K.

             If you can't make it in person, you can take part
           in the Seizing the Media Congress by post, fax, E-mail.

        Send documents, comments, proposals, art, ideas, and posters.

             Post to: BM Jed, London WC1N  3XX, United Kingdom
             Fax to: (011 441) 0865 72 4317
             E-Mail to:  Eastoxcomcen@GN.APC.ORG

      Accommodation and other information are available from Friday night 
      onwards.  To make arrangements or get more information, get in 
      touch with Oxfin between 1-4pm Mondays to Fridays at: (0865) 240545
      >From the United States: 011 41865 240 545

      Background:

      SEIZING THE MEDIA is the title of pamphlet written by the
      Immediast Underground and first released in Amsterdam ,
      New York City, and Seattle in early 1992. The 26 pamphlet
      combines theory, graphics, research and proposals that examine:

                    * Information control
                    * Propaganda and advertising
                    * CIA
                    * Mind control
                    * Immediast counter-offensives
                    * tactics, subversive networking, public empowerment
                    * multi-media
                    * Public production libraries
                    * the liberation of public space

       ...Just when Jesse Helms thought he made the world safe from
       poetic terrorism, along come the Immediasts, a cadre of media 
       hackers who are fed up with the ecology of coercion that 
       surrounds them. Their booklet SEIZING THE MEDIA proposes an 
       all-out artistic assault on coercive communication, cultural 
       monologue, and media control. They want all media insurgents 
       to take back the airwaves with pirate radio, cable access TV, 
       altering ads and billboards, and otherwise hacking the 
       datasphere to break the spell of State/corporate media control.
	  . . . from Gareth Branwyns STREET NOISE, Issue 7 of Mondo 2000

       SEIZING THE MEDIA Version 1.1 is available for $3 from
       Open Media PO Box 2726  Westfield New Jersey 07091 USA

       THE IMMEDIAST UNDERGROUND is a centerless network of artists,
       writiers, hackers, culture jammers, pirate broadcasters, and
       posterists who connect with one another through information
       systems, mail art, networker congresses, and the underground
       press, and who communicate with the public through actions
       against all forms of coercive communication, space
       infringement, and media control.
       For more info contact:
       Immediast U. PO Box 2726  Westfield New Jersey 07091 USA

       DECENTRALIZED WORLD-WIDE NETWORKER CONGRESSES
       Since the beginning of the year, members of alternative
       info-nets, artists, insurgents, and cultural workers have
       been holding networker congresses, transnational engagements 
       in cultural production, dialogue, collaborations, open 
       exchange, subversive brainstorming, and collective 
       disruptions of dominant culture.

       THE NETWORKER, A NEW PERCEPTION
       In societies where information is money and media is power,
       public access is as controlled as the corporate states grip 
       on communication law, censorship, commerce, covert action 
       and surveillance. In this context, uninhibited public 
       communication, expression, and cultural production are acts 
       of freedom, sovereignty, and defiance. Rooted in the drive to 
       connect and exchange with others, Networker Congress engage 
       in culture and media as the battleground for greater openness 
       and freedom.
       
       MORE INFORMATION about NETWORKER CONGRESSES contact:
       
       H.R. Fricker
       Buro fur kunsterische Umtriebe
       CH 9043 Trogen Switzerland
       
       Retrofuturism
       PO Box 2278
       Iowa City, Iowa 52244
       
       Face of the Congress
       FaGaGaGa
       Po Box 1382
       Youngstown, Ohio 44501
       
       Peter Kaufman
       Bergenwissenstrasse 11
       CH-8123 EbmatigenDecentralized Networker Congresses
       Switzerland

       Decentralized Networker Congresses

       Netshaker
       PO Box 978
       Hanover, New Hampshire 03766
       
** End of text from cdp:gen.media **






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: postmastuh@dawkmastuh.guv
Date: Thu, 1 Oct 92 14:35:52 PDT
To: cypherpunks@toad.com
Subject: Secure IRC
Message-ID: <9210012143.AA00610@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


How about the idea of a secure Internet Relay Chat?
 
A central server might maintain the list of everybody's Public Keys.
If you wanted to broadcast a 'public' yet secure msg in a particular
room making sure only participants in that room (and not eavesdroppers
somewhere else on the wire) could read the msg you could encrypt
your broadcast with the server's own Public Key.  Send it.
The Server receives it, decrypts it, then for each of the participants
currently in this particular room, the server encrypts the msg
with that person's Public Key and sends it.  Private IRC msgs
would be treated similarly, except that they'd be re-encrypted
only once, for the intended private recipient.

Anyone interested on working on this?  0r 1z 1t 2 layme?
 
-- /|n0n1mu$




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: omega@spica.bu.edu (The Omega)
Date: Thu, 1 Oct 92 16:16:25 PDT
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9210012324.AA01012@spica.bu.edu>
MIME-Version: 1.0
Content-Type: text/plain



FOR IMMEDIATE RELEASE


Contact:  Nikki Draper  (415) 322-3778


     Computer Public Advocacy Group To Examine FBI Wiretap Scheme
                     at October Annual Meeting.

Palo Alto, Calif., October 1, 1992 -- Computer Professionals for Social
Responsibility (CPSR), the national public interest organization based
here, will take an in-depth look at its recent suit against the Federal
Bureau of Investigation (FBI) during CPSR's 1992 Annual Meeting,
October 17th and 18th at Stanford University in Palo Alto, Calif.
CPSR Legal Counsel, David Sobel, will talk about the FBI suit for the
first time since it was filed and moderate a panel discussion on the
politics of cryptography at the annual meeting.  The CPSR annual
meeting is a provactive two-day conference that addresses critical
issues facing society as a result of information technology.

CPSR filed suit against the FBI in September, after the Bureau failed
to make public documents that would justify the need for its new
wiretap proposal.  The FBI proposal would redesign the telephone
network to make wiretapping easier.  Recognizing the importance of
cryptography policy, CPSR catalyzed a national debate earlier this
year, as to whether or not the FBI and National Security Agency
(NSA) should be involved in setting the technical standards for the
computer and communications industry.

The panel discussion will include a screening and discussion of film
clips from the movie, Sneakers.  Panelists include, Joan Feigenbaum,
Technical Staff, Computing Principles Research, ATT Bell Labs, John
Gilmore, founder of Cygnus Support, and Dave Banisar, CPSR Policy
Analyst.

CPSR's annual meeting will  bring together computer scientists from
across the country to examine the relationship between politics and
technology.  Other topics include:

    *  Teledemocracy & Citizen Participation:
        Beyond the Electronic Town Meeting,

This session is an election year look at the dangers and the
opportunites of electronic democracy.  Speaker, Susan G. Hadden,
professor in the LBJ School of Public Affairs, University of Texas at
Austin, an expert on telecommunications and citizen participation.

    *  Everything's Digital!  Media Convergence:  Hope, Hype or Hell?

This session examines the social implications of multimedia
convergence which is the merging of computer, telephone, and video
technology.  Panel discussion with David Bunnell, Editor, New Media,
Denise Caruso, Editor, Digital Media, and Howard Rheingold, Whole
Earth Review

    *  Envisioning Technology Policy in a Democratic Society;

A panel of technologists looks at the development of American
technology policy.  Panelists include, Gary Chapman, The 21st
Century Project, Judy Stern, CPSR/Berkeley, Claire Zvanski, SEIU
Local 790.

President of Interval Research, Dave Liddle, will be the keynote
speaker at CPSR's awards banquet Saturday evening.  Liddle will be
speaking on the Computing in the 21st Century.  IBM researcher,
Barbara Simons will be presented with the 1992 Norbert Wiener
Award for Social and Professional Responsibility in Computing.

Founded in 1981, CPSR is a national, non-profit, public interest
organization of computer scientists and other professionals concerned
with the impact of computer technology on society.  With offices in
Washington, D.C. and Boston, CPSR's members provide the public and
policy makers with expert testimony and assessments on the power, promise, and
 limitations of computer technology.

For more information about CPSR call 415-322-3778 or send email to
cpsr@csli.stanford.edu.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 2 Oct 92 00:53:02 PDT
To: postmastuh@dawkmastuh.guv
Subject: Re:  Secure IRC
Message-ID: <199210020800.AA21035@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Interesting ideas so far... Hey, anyone see the Quantum Crypto article in
October Scientific AMerican?  Of course the approach isn't practical at this
point, and doing it over fiber optics won't be any better since the
amplification along the way would raise the quantum process to the classical
level and destroy its value... but even so, interesting as theory...
-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Fri, 2 Oct 92 22:26:14 PDT
To: cypherpunks@toad.com
Subject: Re: Secure IRC
Message-ID: <2554.2ACD2FF0@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> How about the idea of a secure Internet Relay Chat?

I'm fairly interested... version 2 of PGP is generating some interest here in the FidoNet, though it has some serious problems, design problems. (It's "ASCII armor" method (ala UUENCODE) is delicate and fussy, for example).

I am considering becoming and "introducer" for parts of FidoNet. I can't seem to get past the problems of how to assign reliability to public keys I receive over an unsecured email channel to begin with.  No other method is practical.

Alas, I can't take part in much it seems, the UFGATE was hobbled to intentionally prevent us FidoNet people from entering text into message headers (For example "Request-Remailing-To:"...) because we'd take over the planet or something I guess (we are apparently contagious).

 U> The Server receives it, decrypts it, then for each of the participants
 U> currently in this particular room, the server encrypts the msg
 U> with that person's Public Key and sends it. 

Doesn't this imply that the unencrypted message would have to travel from the originator to the server? Or do you mean to send to X I'd request X's public key from the server, then encrypt, etc?

--- Msg V2.8
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: omega@spica.bu.edu (The Omega)
Date: Fri, 2 Oct 92 10:35:43 PDT
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9210021743.AA04199@spica.bu.edu>
MIME-Version: 1.0
Content-Type: text/plain



Hacking ingenuity...

=================[ Cut Here ]====================

                  The /etc/passwd cracker service


   Have you ever been troubled by those DES encrypted passwords in the
   /etc/passwd file of your favourite machine ? Worry no more !


What's up ?

   Utopia now has a unique, probably the first in the world,
   password-hacking mailserver. This server compares the encrypted string
   in the /etc/passwd with a 3Mb dictionary, the gecos-field and username.
   The dictionary consists of +- 50.000 english words, +-50.000 dutch
   words, sf-authors, girlnames and some other stuff that people tend to
   use as passwords.

   The dictionary check is done by the very fast HADES hacking engine.
   I was surprised by the speed of hades ! The gecos and username
   scanning is done by the adapted berkeley hacker , this one also appends
   0-9 to the end of the guess, and checks upper/lower case and words
   without vowels.


How it works:

   You need access to some form of uucp/internet mail facilities to use
   the server. Fidonet-users can use the fido <-> internet gateway,
   a helpfile for this gateway can be found somewhere on utopia, and on
   many other systems in cyberspace.


   send your /etc/passwd to: cracker@utopia.hacktic.nl


   The cracker will automagically try to guess the passwords in the
   passwd file, and send you back any results it found to the E-mail
   adress the file came from.


Illegal ?

   Ofcourse you yourselfe are entirely responsible for your actions, I
   really don't care what you do with any passwords from any hacked
   account. I trust you to only use this server for 'educational
   purposes' :) Read the boiler-plate on Utopia to have deeper insight
   in any legal-issues. Furthermore you should read the disclaimer that
   comes with the HADES password hacker.


Thanks:

   Thanks go to Zakbar & Remote for making the HADES hacker, to ITSME
   for the msdos-berkeley hacker, to Rop for the original idea and to
   the cockroaches in my house for entertaining me in those early
   hours.

======================================================================





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Judith Milhon <stjude@well.sf.ca.us>
Date: Sat, 3 Oct 92 18:45:12 PDT
To: cypherpunks@toad.com
Subject: public vs. private
Message-ID: <199210040152.AA17760@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain




marc suggests:
>>I *am* a little worried about publicizing the whole thing;
>>perhaps it's okay to make it a showpiece but
>>the real stuff needs to be done in a much more private way.

Consider the phage model (which I & my roommate efrem lipkin have
been considering for a longish while, since Community Memory) :

The bacteriophage virus replicates itself by injecting its own
information into an existing system. The more copies of the phage,
the worse for the bacteria etc etc. 
SO: in private, the planning, the designing, the coding...
for public distribution as widely as possible. If the technology is
intrinsically transformative, and if the process of distribution is
engaging, even exciting, the revolution is next tuesday.


hughes is hoping that remailers will pop up everywhere, even before the
encryption upgrades arrive... heh. And the more designers and coders we
rope in, via publicizing, to produce immediate lively replicating
phages, the better. Not so? If not so, I'll shut up forthwith.

StJude

PS: also it mindfucks the idea of conspiracy. hee hee.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sun, 4 Oct 92 14:46:44 PDT
To: pozar@kumr.lns.com
Subject: PGP echo conference...
Message-ID: <2573.2ACF6745@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Date: 03 Oct 92 17:22:42 
From: Christopher Baker on 374/14
To:   Tom Jennings on 125/111 Subj: PUBLIC_KEYS Echo announcement

 * Forwarded from 1:374/14, Rights On! in Titusville FL
 * Originally to All in the ECHO_REQ echo.

attention all public-key encryption buffs:

a new Echo has been started for discussion and distribution of public-key encryption info. since it was only born a couple hours ago, it is being distributed privately from 1:374/14 [9600+ HST/V32] and 1:374/26 [2400].

 here are the details from the EListing:

area  PUBLIC_KEYS

title  Public-Key Encryption and Distribution Echo

desc  Provides a technical forum for discussion of public-key desc  encryption techniques and programs and for the distribution desc  of public-keys in FidoNet and other BBS and e-mail networks.  desc  PUBLIC_KEYS is Moderated by Christopher Baker at 1:374/14 desc  [KeyID: 1024/4B9A59] and GK Pace at 1:374/26 [KeyID: desc  1024/B6B823]. The messages entered into the Echo are the sole desc  responsibility of the person entering the messages.  When in desc  doubt about public-keys, contact the poster directly via Netmail.  desc  The Echo is open to anyone with an interest in public-key desc 

encryption issues and methods. The Echo Guidelines are contained desc  in PUBKEYS.RUL available in ELRUL???.LZH as of 11/92.

 mod   C.Baker/GK.Pace, 1:374/14

tot   2

vol   10/week

dist  LOCAL, ZONE1

SEEN  374/14 374/26

PATH  374/14 374/26

-30-

here's the info from the .RUL file to be found in ELRUL as of 11/92:



This is the PUBLIC_KEYS Echo. The purpose of the Echo is to provide a place to post and find public-keys for data encryption within FidoNet and elsewhere and to discuss data and software encryption and the various schemes thereof.

 This is a technical Echo with very few rules. Those very few rules are:

1. Stay on-topic. Topics of keys and encryption are welcome. Others are not.

 2. No politics [except as it relates to privacy issues] and no religion.

 3. No personal attacks, slurs or innuendo. Stick to issues not

  personalities.

 4. No Private flagged messages in Echomail! Encrypted traffic using

  public-keys is permitted for the exercise so long as it is on-topic.

 5. This Echo may be traveling around the world so try to be concise. Avoid

  excessive quoting for one-liner responses.

 6. Be aware that Echomail is NOT secure. Don't take anything at face value.

 7. The posts in this Echo are the sole responsiblity of the poster. If you

  need verification, use Netmail.

 8. The Moderators will deal with off-topic traffic. Don't respond for them.

  Links to this Echo will only be curtailed when absolutely necessary so

  please don't make it necessary. [grin]

The Moderators are Christopher Baker [KeyID: 1024/4B9A59 1992/10/03] and GK Pace [KeyID: 1024/B6B823 1992/09/28] at 1:374/14 and 1:374/26, respectively.

 It is recommended that public-keys be made available via Netmail or by file-request with the magic filename: PGPKEY and that the public-key provided for that request by given a distinctive filename using part or all of each provider's name and address. For example, on my system, a file-request of PGPKEY will give BAK37414.ASC to the requesting system. This will avoid duplicate overwriting and make it easier to track the keys. Using a standard magic filename will make it easier to find keys on different systems.

 This Echo is not currently on the Zone 1 Backbone distribution list but that is expected to change as soon as the word gets out. This Echo will be EListed in ELIST211 next month. Please feel free to announce and distribute this Echo to all interested participants in your area.

 Thanks.

 TTFN.  Christopher Baker & GK Pace Moderators

-30-

any questions? anyone with Areafix already set for this system or for 1:374/26 may link in remotely. all others need to send a Netmail request. the Echo will be distributed privately until it is large enough for moving to the Zone 1 Backbone [or any other Backbones who want to get into it].

 thanks.

 TTFN.  Chris & GK

* Origin: Rights On! - Announcing ANOTHER Echo? - Titusville_FL (1:374/14)

* Forwarded by Christopher Baker on 1:374/14, Rights On! in Titusville FL

--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Secret_Squirrel@Treehouse.ORG
Date: Sat, 3 Oct 92 22:38:36 PDT
To: cypherpunks@toad.com
Subject: Nuts & Acorns
Message-ID: <9210040546.AA10254@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


To: Tom Jennings
 
>>
Doesn't this imply that the unencrypted message would have to travel
from the originator to the server? Or do you mean to send to X I'd
request X's public key from the server, then encrypt, etc?
<<
 
Not at all.  In its simplest form: We'd have a single
secure-IRC-server.  It would have its own public key, which ever
secure-IRC-client would know.  When I want to send a secure
broadcast msg, I type it, my client encrypts it with the public key of
the secure-IRC-server, and transmits it.  The server picks it up,
decrypts it in memory, then re-encrypts that original msg with the
public key of each paritxxx participant in the particular room I'm in.
So, if there are ten participants in the room, and I want all of them
to know something, but not anyone else who might be tapping ixxx wires
or catching packets somewhere in the ether, then I'd send a single
broadcast msg to the server; the server would end up sending ten
differently encrypted msgs -- one to each participant, encrypted with
each of the participants' public keys (which the secure-irc-server
would have to maintain; it would function as a key-server.)
 
To send a private msg across the secure-IRC, I'd indicate that it was
a "/msg", the recipeixxx recipient, and again, encrypt it with the
public key of the server.  The server would learn who the recipient
was, and rebroadcast my message to that person, in that person's
public key.
 
>>
I am considering becoming and "introducer" for parts of FidoNet. I
can't seem to get past the problems of how to assign reliability to
public keys I receive over an unsecured email channel to begin with.
No other method is practical.
<<
 
Huh?  I don't understand what you're pointing out.  If I send you my
public key -- even if I cc: dockmaster -- what does it matter that the
NSA knows my public key (unoless they want to send me msgs, too)?  The
key itself is inherantly secure.  Let your users decide on their
public keys and register those keys with your key server.  Not the
other way around.  Course, there's always the Kandinsky-Ogorov method
of key exchange.
 
To: St. Jude
 
>>
The bacteriophage virus replicates itself by injecting its own
information into an existing system. The more copies of the phage,
the worse for the bacteria etc etc. 
SO: in private, the planning, the designing, the coding...
for public distribution as widely as possible. If the technology is
intrinsically transformative, and if the process of distribution is
engaging, even exciting, the revolution is next tuesday.
<<
 
Providing the numbe r of cells you have access to and can anticipate
influencyxxx incxxx influencing is large enough, and it isn't.
 
Anyway, look, let's put our words into action.  What makes code
(programming, I mean) didxxx different from spoken language?  The fact
that you can communicate with a machine, and it will _act_ on what you
say, no matter what.  Theres beauty and there's magic in that.  (And
some of us have the same effect on people that we have on machines.
;-)) Instead of talking about all this, let's start doing it.  What
did I read the other day?  "Hackers go where Angels fear to tread"?
Let's have more ideas.  This hopping remailer is exciting.  So is
passive encryption of electronic communications.  When are we going
totart xxx to start effecting de facto standards here?  Once we start
encrypting everything, then what?  What do we do with this new tool?
Communication of any kind (especially encrypted communication)
presupposs that there are messages to be exchanged -- _ideas_!  More
ideas and less chatter.
 
How can we have a revolution if we don't even know what we're trying
to bring about?  Maybe I was out of the loop.  Maybe I was attending
an Army/Navy game that day, but I don't know what we're trying to do
here, exactly.  What is this "revolution"?  
 
-- $33kr1t $kwurl.
    K.R.A.P.  (K-Rad. A.SCII P.Ossee)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sun, 4 Oct 92 18:59:32 PDT
To: cypherpunks@toad.com
Subject: Secure IRC
In-Reply-To: <9210012143.AA00610@atdt.org>
Message-ID: <9210050206.AA20902@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



The problem with central servers is that they are prone to single
point failure.  That failure may be computer down or key compromise.
A good criterion for this kind of design is not to use central
servers.  This is almost always possible.  (Or always possible,
depending on who you ask.)

There is also the question about getting permission to enter a room,
which corresponds to an authentication or a key distribution or a
voting algorithm or some sort.  You need to know how you want that
_social_ interaction to work before you design protocols.  You should
implement that sociality and test it without encryption to make sure
it's what you want.  Is this sounding familiar?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sun, 4 Oct 92 19:15:03 PDT
To: cypherpunks@toad.com
Subject: introducing public keys
In-Reply-To: <2554.2ACD2FF0@fidogate.FIDONET.ORG>
Message-ID: <9210050222.AA21567@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>I am considering becoming and "introducer" for parts of FidoNet. I
>can't seem to get past the problems of how to assign reliability to
>public keys I receive over an unsecured email channel to begin with.
>No other method is practical.

Building a key distribution system takes time.  Start off by having
people mail you diskettes.  Or if you don't mind typing, printouts.
Carry copies of your public key to give to people in person.

Get good security is not free, especially in terms of time.

If you can personally receive via out-of-band channels the public key
of another introducer, you can exchange all the certified keys you
each possess.  And then exchange those with another introducer you know.

Introducers are not a special breed.  Most people should certify
others public keys, if only for redundancy.

Remember, no one has ever set up a non-hierarchical public key
distribution system to the general public.  This is research.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sun, 4 Oct 92 19:17:52 PDT
To: cypherpunks@toad.com
Subject: Mail headers
In-Reply-To: <2554.2ACD2FF0@fidogate.FIDONET.ORG>
Message-ID: <9210050225.AB21620@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>Alas, I can't take part in much it seems, the UFGATE was hobbled to
>intentionally prevent us FidoNet people from entering text into
>message headers (For example "Request-Remailing-To:"...) because we'd
>take over the planet or something I guess (we are apparently
>contagious).

You aren't the only one Tom.  Apparently lots of Unix mail interfaces
don't let you arbitrarily edit the header or add lines.

I'm going to add a facility to make this possible for everyone.  The
design I have in mind uses only the message body.  No need to touch
the header.

Announcements when it's finished.

Eric





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sun, 4 Oct 92 19:51:17 PDT
To: cypherpunks@toad.com
Subject: introducers
In-Reply-To: <9210040546.AA10254@atdt.org>
Message-ID: <9210050258.AA22363@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>If I send you my public key -- even if I cc: dockmaster -- what does
>it matter that the NSA knows my public key (unoless they want to send
>me msgs, too)?  The key itself is inherantly secure.  Let your users
>decide on their public keys and register those keys with your key
>server.  Not the other way around.

Let's make this short.

The basic problem with public key systems is to make sure that what
_I_ think is my public key is the same thing as what _you_ think is my
public key.

If these are not the same, something is wrong.  At worst, an
interposer is getting all your mail, decrypting with one public key
and encrypting with a different one.

Servers, generally, are not desirable because they are too prone to
communications filters of the above sort.

For a more detailed reference, read the excellent introduction to the
whole topic of public key distribution in the PGP 2.0 documentation.


>Course, there's always the Kandinsky-Ogorov method of key exchange.

Please elaborate.


Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 5 Oct 92 00:14:29 PDT
To: cypherpunks@toad.com
Subject: A statement of purpose
Message-ID: <9210050721.AA01865@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I've had a bunch of people ask me about the group and what it's up to.
Accordingly, I drafted a small statement of purpose to send to folks.

Please comment.

Eric

----------------------

The cypherpunks list is a forum for discussion about technological
defenses for privacy in the digital domain.  

Cypherpunks assume privacy is a good thing and wish there were more
of it.  Cypherpunks acknowledge that those who want privacy must
create it for themselves and not expect governments, corporations, or
other large, faceless organizations to grant them privacy out of
beneficence.  Cypherpunks know that people have been creating their
own privacy for centuries with whispers, envelopes, closed doors, and
couriers.  Cypherpunks do not seek to prevent other people from
speaking about their experiences or their opinions.

The most important means to the defense of privacy is encryption. To
encrypt is to indicate the desire for privacy.  But to encrypt with
weak cryptography is to indicate not too much desire for privacy.
Cypherpunks hope that all people desiring privacy will learn how best
to defend it.

Cypherpunks are therefore devoted to cryptography.  Cypherpunks wish
to learn about it, to teach it, to implement it, and to make more of
it.  Cypherpunks know that cryptographic protocols make social
structures.  Cypherpunks know how to attack a system and how to
defend it.  Cypherpunks know just how hard it is to make good
cryptosystems.

Cypherpunks love to practice.  They love to play with public key
cryptography.  They love to play with anonymous and pseudonymous mail
forwarding and delivery.  They love to play with DC-nets.  They love
to play with secure communications of all kinds.

Cypherpunks write code.  They know that someone has to write code to
defend privacy, and since it's their privacy, their going to write
it.  Cypherpunks publish their code so that their fellow cypherpunks
may practice and play with it.  Cypherpunks realize that security is
not built in a day and are patient with incremental progress.

Cypherpunks don't care if you don't like the software they write. 
Cypherpunks know that software can't be destroyed.  Cypherpunks know
that a widely dispersed system can't be shut down.

Cypherpunks will make the networks safe for privacy.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 5 Oct 92 01:23:23 PDT
To: cypherpunks@toad.com
Subject: Meeting Sat. Oct. 10, noon, Mt. View
Message-ID: <9210050830.AA03692@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



ANNOUNCEMENT
============

Second Meeting

Saturday, October 10, 1992
12:00 noon - 6:00 p.m.

Cygnus Support offices
1937 Landings Drive
Mountain View


The second meeting of the cypherpunks will be Saturday at noon.  John
Gilmore has graciously provided us with a meeting space at the new
Cygnus Support offices.  These offices are so new, in fact, that
Cygnus will not have moved in yet.  This meeting will be
bring-your-own-pillow (or chair), since it will be held in largely
empty space.  Directions are at the end of the message.

Attendance is transitive trust, arbitrarily deep.  Invite whoever you
want, and let them do so also, and so on.  Invite them also to join
the mailing list.  Do not, however, just post the announcement.  Time
for that will come.

I'd like everyone who plans on attending the meeting to send me,
hughes@soda.berkeley.edu, a message telling me so.  I'd like to get a
rough head count before Saturday for game planning.

We are starting at noon because of popular demand.  Eat beforehand or
bring a burrito or something.  It will be fine to eat during the first
segment; it won't be any more disruptive than the game is.

Bring your PGP public key for in-person key distribution, preferably
on diskette.  We'll need a portable PC or three to do key
distribution; if you have one you can bring, post to the list and tell
people.

We realized after the first meeting that a strict schedule was
nonsense.  This meeting has a very informal schedule.


Schedule
--------

Starting at noon, we're going to play session two of the
crypto-anarchy game, in which players try to conduct business under
the watchful eyes of others.  We want to play for two hours and then
have discuss experiences afterward for about an hour.  Some of the
improvements over last time will be flatter denominations of money,
wider distribution of commodities, more watchers (governmental and
otherwise), and perhaps some pre-printed forms.

We'll take a break to regroup for about ten or twenty minutes.

For the second half we'll talk about the security of remailers.  I'll
lead the discussion.  We'll be designing protocols and analyzing
attacks and defenses.  I've done this with DigiCash for electronic
money protocols, and remailers are much easier, but still probably
more than an afternoon's discussion.  We'll do this until six or so,
when people will have to start leaving.

Everyone who wants to will go out for dinner.  I don't know the
restaurants down there; perhaps someone could suggest one?


Directions
----------
It's at 1937 Landings Drive, Mt. View.  101 to Amphitheatre Parkway
(the bay side of Rengstorff Ave), go right at the first light,
pass a right turn, and just before the road crests a tiny hill,
turn right into the Landings complex.  We're in Building H.


--
Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Fen Labalme" <fen@genmagic.com>
Date: Mon, 5 Oct 92 12:39:37 PDT
To: "Eric Hughes" <uunet!soda.berkeley.edu!hughes@uunet.UU.NET>
Subject: Re: A statement of purpose
Message-ID: <9210051947.AA29863@relay1.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


Subject:  RE>A statement of purpose


I am way excited to see this all coming together!  It's like a 13-year-
old dream-come-true!

This is a great statement of purpose, though I might leave "DC-nets" out
(since many won't know what that means) and perhaps replace it with the
only slightly-less-cryptic "information-theoretically-secure networks",
or some such.

$0.02






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Fen Labalme" <fen@genmagic.com>
Date: Mon, 5 Oct 92 14:13:51 PDT
To: "Cypher Punks" <cypherpunks@toad.com>
Subject: SEIZING THE MEDIA
Message-ID: <9210052121.AA03803@relay2.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


Subject:  SEIZING THE MEDIA

[ this is a resend
  I originally sent this to cypherpunks@toad.com on 28 Sep, but I haven't
  seen it yet, so apologies up front if you see it twice...

  Fen
  ~~~ ]

FYI...

from PeaceNet ACTIV-L:

Date:         Sat, 26 Sep 1992 23:33:10 CDT
Sender: Activists Mailing List <ACTIV-L%MIZZOU1.BITNET@pucc.Princeton.EDU>
>From: "(Rich Winkel)" <rich@pencil.cs.missouri.edu>
Subject:      PAX: SEIZING THE MEDIA: A NETWORKER CONGRESS
To: Multiple recipients of ACTIV-L <ACTIV-L%MIZZOU1.BITNET@pucc.Princeton.EDU>

/** gen.media: 141.0 **/
** Topic: SEIZING THE MEDIA: NETWORKER CONGR **
** Written  6:39 pm  Sep 25, 1992 by openmedia in cdp:gen.media **

                  SEIZING THE MEDIA:  A NETWORKER CONGRESS
               A weekend of activity to discuss, self-educate,
           and put into practice the creation of subversive media.

           1:30pm Saturday 24 October to 6pm Sunday 25 October 1992

             Media and resource exchange;  slides, fax, posters, 
	     pamphlets, computer files, ideas, proposals, tactics

            Practical action on billboard improvement and removal;
                           Big Art and postering

               E-mail and fax facility to receive material 
	    to be discussed and implemented during the weekend

                     Documentation to all participants

        Materials supplied:  photocopier reproduction/enlargement 
      	 and the streets of Oxford
       Bloomin Arts, Princes Street, Cowley Road, Oxford, OX4, U.K.

             If you can't make it in person, you can take part
           in the Seizing the Media Congress by post, fax, E-mail.

        Send documents, comments, proposals, art, ideas, and posters.

             Post to: BM Jed, London WC1N  3XX, United Kingdom
             Fax to: (011 441) 0865 72 4317
             E-Mail to:  Eastoxcomcen@GN.APC.ORG

      Accommodation and other information are available from Friday night 
      onwards.  To make arrangements or get more information, get in 
      touch with Oxfin between 1-4pm Mondays to Fridays at: (0865) 240545
      >From the United States: 011 41865 240 545

      Background:

      SEIZING THE MEDIA is the title of pamphlet written by the
      Immediast Underground and first released in Amsterdam ,
      New York City, and Seattle in early 1992. The 26 pamphlet
      combines theory, graphics, research and proposals that examine:

                    * Information control
                    * Propaganda and advertising
                    * CIA
                    * Mind control
                    * Immediast counter-offensives
                    * tactics, subversive networking, public empowerment
                    * multi-media
                    * Public production libraries
                    * the liberation of public space

       ...Just when Jesse Helms thought he made the world safe from
       poetic terrorism, along come the Immediasts, a cadre of media 
       hackers who are fed up with the ecology of coercion that 
       surrounds them. Their booklet SEIZING THE MEDIA proposes an 
       all-out artistic assault on coercive communication, cultural 
       monologue, and media control. They want all media insurgents 
       to take back the airwaves with pirate radio, cable access TV, 
       altering ads and billboards, and otherwise hacking the 
       datasphere to break the spell of State/corporate media control.
	  . . . from Gareth Branwyns STREET NOISE, Issue 7 of Mondo 2000

       SEIZING THE MEDIA Version 1.1 is available for $3 from
       Open Media PO Box 2726  Westfield New Jersey 07091 USA

       THE IMMEDIAST UNDERGROUND is a centerless network of artists,
       writiers, hackers, culture jammers, pirate broadcasters, and
       posterists who connect with one another through information
       systems, mail art, networker congresses, and the underground
       press, and who communicate with the public through actions
       against all forms of coercive communication, space
       infringement, and media control.
       For more info contact:
       Immediast U. PO Box 2726  Westfield New Jersey 07091 USA

       DECENTRALIZED WORLD-WIDE NETWORKER CONGRESSES
       Since the beginning of the year, members of alternative
       info-nets, artists, insurgents, and cultural workers have
       been holding networker congresses, transnational engagements 
       in cultural production, dialogue, collaborations, open 
       exchange, subversive brainstorming, and collective 
       disruptions of dominant culture.

       THE NETWORKER, A NEW PERCEPTION
       In societies where information is money and media is power,
       public access is as controlled as the corporate states grip 
       on communication law, censorship, commerce, covert action 
       and surveillance. In this context, uninhibited public 
       communication, expression, and cultural production are acts 
       of freedom, sovereignty, and defiance. Rooted in the drive to 
       connect and exchange with others, Networker Congress engage 
       in culture and media as the battleground for greater openness 
       and freedom.
       
       MORE INFORMATION about NETWORKER CONGRESSES contact:
       
       H.R. Fricker
       Buro fur kunsterische Umtriebe
       CH 9043 Trogen Switzerland
       
       Retrofuturism
       PO Box 2278
       Iowa City, Iowa 52244
       
       Face of the Congress
       FaGaGaGa
       Po Box 1382
       Youngstown, Ohio 44501
       
       Peter Kaufman
       Bergenwissenstrasse 11
       CH-8123 EbmatigenDecentralized Networker Congresses
       Switzerland

       Decentralized Networker Congresses

       Netshaker
       PO Box 978
       Hanover, New Hampshire 03766
       
** End of text from cdp:gen.media **






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Secret_Squirrel@Treehouse.COM
Date: Mon, 5 Oct 92 21:40:53 PDT
To: cypherpunks@toad.com
Subject: List
Message-ID: <9210060448.AA02547@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


comp-privacy@pica.army.mil
 
   I am the moderator of the Computer Privacy Digest.  The computer
   Privacy Digest is an Internet mailing list that is dedicated to the
   discussion of how technology impacts privacy.  This list is
gatewayed
   into the moderated USENET newsgroup comp.society.privacy.  In lot
of
   ways it is a subsection on the risks digest but it concentrates on
   the risks of technology on privacy.  The charter is:
 
   comp.society.privacy    Effects of technology on privacy
(Moderated)
 
   This newsgroup is to provide a forum for discussion on the effect
of
   technology on privacy. All too often technology is way ahead of the
   law and society as it presents us with new devices and
   applications.  Technology can enhance and detract from privacy.
   This newsgroup will be gatewayed to an internet mailing list.
 
   Submissions go to: comp-privacy@pica.army.mil and administrative
   requests go to comp-privacy-request@pica.army.mil.
 
   Moderator:  Dennis G. Rears
      MILNET:  drears@pica.army.mil    UUCP:
...!uunet!cor5.pica.army.mil!drears
      INTERNET: drears@pilot.njin.net  USPS:  Box 210, Wharton, NJ
07885
      Phone(home): 201.927.8757        Phone(work): 201.724.2683/(DSN)
880.2683
      USPS:     SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806
 
----------------------[ Cut Here ]------------------
 
I , Secret Squirrel, am merely cross-posting the above.
I have nothing to do with it, and am in now xxx no way connected
with comp-privacy.  Just thought it might interest someone here.
 
Quakka!




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 6 Oct 92 15:11:44 PDT
To: cypherpunks@toad.com
Subject: re: Nuts & Acorns
Message-ID: <2654.2AD20C59@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 > To: Tom Jennings
 
tj>>
I am considering becoming and "introducer" for parts of FidoNet. I
can't seem to get past the problems of how to assign reliability to
public keys I receive over an unsecured email channel to begin with.
No other method is practical.
<<
 
>>??
Huh?  I don't understand what you're pointing out.  If I send you my
public key -- even if I cc: dockmaster -- what does it matter that the
NSA knows my public key (unoless they want to send me msgs, too)? 
<<

Not my worry. What I meant was, how do I know htat the keyfile I
received from "John Smith @ net address" really is his, and not some
faker. Short of physically getting key disks from someone face to
face (flatly im-possible here), I don't know.

The assurance of course is the social system: if someone sends me a
message and keyfile, "here's my file, my name is Eric Hughes", and I
distribute it...

I can think of no way to prevent this, other than let a social system
detect and repair -- "HEY THATS NOT ME!!!" form the 'real' you would
raise a flag... and an audit trail at the introducers site
(dangerous...!) might help.

Anyhoo, that's what I meant.
--- RM version 0.-1 (watch out)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Fen Labalme" <fen@genmagic.com>
Date: Tue, 6 Oct 92 18:15:28 PDT
To: "Cypher Punks" <cypherpunks@toad.com>
Subject: crypto bibliography
Message-ID: <9210070123.AA01922@relay2.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


Subject:  crypto bibliography

By anonymous ftp from rsa.com:
Fen
~~~

@inproceedings{agnew,
  author = "Agnew, G.B. and Mullin, R.C. and Vanstone, S.A.", 
  year = 1988,
  title = "A secure public key protocol based on discrete exponentiation",
  booktitle = "Advances in Cryptology --- Eurocrypt '88",
  publisher = "Springer-Verlag",
  address = "Berlin"}

@book{bamford,
  author = "Bamford, J.",
  year = 1982,
  title = "The Puzzle Palace",
  publisher = "Houghton Mifflin",
  address = "Boston"}

@article{barlow,
  author = "Barlow, J.P.",
  year = 1992,
  month = "July",
  title = "Decrypting the puzzle palace",
  journal = "Communications of the ACM",
  volume = 35,
  number = 7,
  pages = "25--31"}

@article{beauchemin,
  author = "Beauchemin, P. and Brassard, G. and Crepeau, C. and Goutier, C.
            and Pomerance, C.",
  year = 1988,
  title = "The generation of random numbers that are probably prime",
  journal = "J. of Cryptology", 
  volume = 1, 
  pages = "53--64"}

@inproceedings{berson,
  author = "Berson, T.A.", 
  year = 1992,
  title = "Differential cryptanalysis mod $2^{32}$ with applications to {MD5}",
  booktitle = "Advances in Cryptology --- Eurocrypt '92",
  publisher = "Springer-Verlag",
  address = "Berlin",
  note = "To appear"}

@inproceedings{biham-feal,
  author = "Biham, E. and Shamir, A.", 
  year = 1991,
  title = "Differential cryptanalysis of {F}eal and {N}-hash",
  booktitle = "Advances in Cryptology --- Eurocrypt '91",
  publisher = "Springer-Verlag",
  address = "Berlin"}

@inproceedings{biham-full-des,
  author = "Biham, E. and Shamir, A.", 
  year = 1993,
  title = "Differential cryptanalysis of the full 16-round {DES}", 
  booktitle = "Advances in Cryptology --- Crypto '92",
  publisher = "Springer-Verlag",
  address = "New York",
  note = "To appear"}

@article{bishop,
  author = "Bishop, M.", 
  year = 1991,
  title = "Privacy-enhanced electronic mail", 
  journal = "Internetworking: Research and Experience", 
  volume = 2, 
  pages = "199--233"}

@inproceedings{blum-g,
  author = "Blum, M. and Goldwasser, S.", 
  year = 1985,
  title = "An efficient probabilistic public-key encryption scheme which 
           hides all partial information", 
  booktitle = "Advances in Cryptology --- Crypto '84",
  pages = "289--299", 
  publisher = "Springer-Verlag",
  address = "New York"}

@inproceedings{brandt,
  author = "Brandt, J. and Damgard, I.", 
  year = 1993, 
  title = "On generation of probable primes by incremental search", 
  booktitle = "Advances in Cryptology --- Crypto '92", 
  publisher = "Springer-Verlag", 
  address = "New York",
  note = "To appear"}

@book{brassard,
  author = "Brassard, G.", 
  year = 1988,
  title = "Modern Cryptology", 
  publisher = "Springer-Verlag"}

@book{bressoud,
  author = "Bressoud, D.M.", 
  year = 1989,
  title = "Factorization and Primality Testing", 
  publisher = "Springer-Verlag",
  address = "New York"}

@article{brickell-survey,
  author = "Brickell, E.F. and Odlyzko, A.M.",
  year = 1988,
  title = "Cryptanalysis: {A} survey of recent results", 
  journal = "Proceedings of the IEEE", 
  volume = 76, 
  pages = "578--593"}

@inproceedings{brickell-rsa-hardware,
  author = "Brickell, E.F.", 
  year = 1989,
  title = "A survey of hardware implementations of {RSA}", 
  booktitle = "Advances in Cryptology --- Crypto '89",
  publisher = "Springer-Verlag",
  address = "New York",
  pages = "368--370"}

@unpublished{buhler,
  author = "Buhler, J.P. and Lenstra, H.W. and Pomerance, C.", 
  year = 1992,
  title = "Factoring integers with the number field sieve", 
  note = "To appear"}

@article{burmester,
  author = "Burmester, M.V.D. and Desmedt, Y.G. and Beth, T.", 
  year = 1992,
  title = "Efficient zero-knowledge identification schemes for smart cards", 
  journal = "Computer Journal", 
  volume = 35, 
  pages = "21--29"}

@inproceedings{campbell,
  author = "Campbell, K.W. and Wiener, M.J.", 
  year = 1993,
  title = "Proof that {DES} is not a group",
  booktitle = "Advances in Cryptology --- Crypto '92",
  publisher = "Springer-Verlag",
  address = "New York",
  note = "To appear"}

@article{canfield,
  author = {Canfield, E.R. and Erd\"{o}s, P. and Pomerance, C.},
  year = 1983,
  title = "On a problem of Oppenheim concerning `Factorisatio Numerorum'",
  journal = "J. Number Theory",
  volume = 17,
  pages = "1--28"}

@manual{X.509,
  author = "{CCITT (Consultative Committee in International Telegraphy
                   and Telephony)}",
  year = 1988,
  title = "Recommendation X.509: The Directory---Authentication Framework"}

@manual{etebac,
  author = "{Comit\'{e} Fran\c{c}ais d'Organisation et de Normalisation 
                  Bancaire}",
  year = 1989,
  title = "Echanges T\'{e}l\'ematiques entre les Banques et leurs Clients, 
           Standard ETEBAC 5, v1.1", 
  address = "Paris"}

@manual{gao-edi,
  author = "{Comptroller General of the United States}",
  year = 1991,
  month = "December 13,",
  title = "Matter of {National Institute of Standards and Technology} ---
           {Use} of Electronic Data Interchange Technology to Create
           Valid Obligations",
  note = "File B-245714"}

@article{coppersmith-o-s,
  author = "Coppersmith, D. and Odlyzko, A.M. and Schroeppel, R.", 
  year = 1986,
  title = "Discrete logarithms in {GF(p)}", 
  journal = "Algorithmica", 
  volume = 1, 
  pages = "1--15"}

@article{coppersmith,
  author = "Coppersmith, D.",
  year = 1987,
  title = "Cryptography",
  journal = "IBM J. Res. Develop.",
  volume = 31,
  number = 2,
  month = "March",
  pages = "244--248"}

@techreport{improving-security-UNIX,
  author = "Curry, David A.",
  year = 1990,
  title = "Improving the Security of Your {UNIX} System",
  institution = "{SRI} International",
  number = "ITSTD-721-FR-90-21",
  address = "Menlo Park, CA",
  month = "April"}

@techreport{davida,
  author = "Davida, G.", 
  year = 1982,
  title = "Chosen signature cryptanalysis of the RSA public key cryptosystem",
  number = "TR-CS-82-2", 
  institution = "Dept of EECS, University of Wisconsin, Milwaukee"}

@book{davies-and-price,
  author = "Davies, D.W. and W.L. Price",
  year = 1984,
  title = "Security for Computer Networks: {An} Introduction to Data Security
           in Teleprocessing and Electronic Funds Transfer",
  publisher = "John Wiley \& Sons",
  address = "New York"}

@manual{green-book,
  author = "{Department of Defense}",
  title = "{CSC-STD-002-85}: Department of Defense ({DoD}) Password Management
           Guidelines",
  year = 1985}

@manual{orange-book,
  author = "{Department of Defense}",
  title = "{DoD 5200.28-STD}: Department of Defense ({DoD}) Trusted Computer
            System Evaluation Criteria ({TCSEC})",
  year = 1985}

@article{diffie-hellman,
  author = "Diffie, W. and Hellman, M.E.", 
  year = 1976,
  title = "New directions in cryptography", 
  journal = "IEEE Transactions on Information Theory", 
  volume = "IT-22", 
  pages = "644--654"}

@article{diffie-hellman-des,
  author = "Diffie, W. and Hellman, M.E.", 
  year = 1977,
  title = "Exhaustive cryptanalysis of the {NBS Data Encryption Standard}", 
  journal = "Computer", 
  volume = 10, 
  pages = "74--84"}

@article{Diffie-Hellman-Intro,
  author = "Diffie, W. and M.E. Hellman",
  year = 1979,
  month = "March",
  title = "Privacy and authentication: {An} introduction to cryptography",
  journal = "Proceedings of the IEEE",
  volume = 67,
  number = 3,
  pages = "397--427"}

@article{diffie-10yrs,
  author = "Diffie, W.", 
  year = 1988, 
  title = "The first ten years of public-key cryptography", 
  journal = "Proceedings of the IEEE", 
  volume = 76, 
  pages = "560--577"}

@article{elgamal,
  author = "ElGamal, T.", 
  year = 1985,
  title = "A public-key cryptosystem and a signature scheme based on 
           discrete logarithms", 
  journal = "IEEE Transactions on Information Theory", 
  volume = "IT-31",
  pages = "469--472"}

@inproceedings{fiat,
  author = "Fiat, A. and Shamir, A.", 
  year = 1987,
  title = "How to prove yourself: {Practical} solutions to identification 
           and signature problems", 
  booktitle = "Advances in Cryptology --- Crypto '86", 
  pages = "186--194", 
  publisher = "Springer-Verlag",
  address = "New York"}

@article{goldwasser,
  author = "Goldwasser, S. and Micali, S.", 
  year = 1984,
  title = "Probabilistic encryption", 
  journal = "J. of Computer and System Sciences", 
  volume = 28, 
  pages = "270--299"}

@inproceedings{gordon,
  author = "Gordon, D.M. and McCurley, K.S.", 
  year = 1993,
  title = "Massively parallel computation of discrete logarithms",
  booktitle = "Advances in Cryptology --- Crypto '92",
  publisher = "Springer-Verlag",
  address = "New York",
  note = "To appear"}

@inproceedings{haber,
  author = "Haber, S. and Stornetta, W.S.", 
  year = 1991,
  title = "How to time-stamp a digital document",
  booktitle = "Advances in Cryptology --- Crypto '90",
  publisher = "Springer-Verlag",
  address = "New York",
  pages = "437--455"}

@article{hastad,
  author = "Hastad, J.", 
  year = 1988,
  title = "Solving simultaneous modular equations of low degree",
  journal = "SIAM J. Computing", 
  volume = 17, 
  pages = "336--241"}

@article{hellman,
  author = "Hellman, M.E.", 
  year = 1980,
  title = "A cryptanalytic time-memory trade off", 
  journal = "IEEE Transactions on Information Theory",
  volume = "IT-26", 
  pages = "401--406"}

@manual{iso9796,
  author = "{International Standards Organization}", 
  title = "IS 9796: Information technology, security techniques: digital 
           signature scheme giving message recovery",
  address = "Geneva, Switzerland"}

@book{kahn,
  author = "Kahn, D.", 
  year = 1967,
  title = "The Codebreakers", 
  publisher = "Macmillan Co.", 
  address = "New York"}

@article{kaliski,
  author = "Kaliski Jr., B.S. and Rivest, R.L. and Sherman, A.T.", 
  year = 1988,
  title = "Is the Data Encryption Standard a group?", 
  journal = "J. of Cryptology", 
  volume = 1, 
  pages = "3--36"}

@article{Kaliski-one-way-permutations,
  author = "{Kaliski Jr.}, Burton S.",
  year = 1991,
  title = "One-Way Permutations on Elliptic Curves",
  journal = "Journal of Cryptology",
  volume = 3,
  pages = "187--199"}

@manual{MD2,
  author = "Kaliski, B.",
  year = 1992,
  month = "April",
  title = "RFC 1319: The {MD2 Message-Digest Algorithm}",
  organization = "Internet Activities Board"}

@manual{rfc1114,
  author = "Kent, S. and J. Linn",
  year = 1989,
  month = "August",
  title = "RFC 1114: Privacy Enhancement for Internet Electronic Mail: Part
           {II} -- Certificate-Based Key Management",
  organization = "Internet Activities Board"}

@book{knuth,
  author = "Knuth, D.E.", 
  year = 1981,
  title = "The Art of Computer Programming",
  edition = "2nd",
  volume = 2, 
  publisher = "Addison-Wesley",
  address = "Reading, Mass."}

@article{koblitz-ecc,
  author = "Koblitz, N.", 
  year = 1987,
  title = "Elliptic curve cryptosystems", 
  journal = "Mathematics of Computation", 
  volume = 48,
  pages = "203--209"}

@book{koblitz,
  author = "Koblitz, N.", 
  year = 1987,
  title = "A Course in Number Theory and Cryptography", 
  publisher = "Springer-Verlag",
  address = "New York"}

@inproceedings{lai,
  author = "Lai, X. and Massey, J.L.", 
  year = 1991,
  title = "A proposal for a new block encryption standard", 
  booktitle = "Advances in Cryptology --- Eurocrypt '90", 
  pages = "389--404", 
  publisher = "Springer-Verlag",
  address = "Berlin"}

@article{lamacchia,
  author = "LaMacchia, B.A. and Odlyzko, A.M.", 
  year = 1991,
  title = "Computation of discrete logarithms in prime fields", 
  journal = "Designs, Codes and Cryptography", 
  volume = 1, 
  pages = "47--62"}

@article{landau,
  author = "Landau, S.", 
  year = 1988,
  title = "Zero knowledge and the {Department of Defense}", 
  journal = "Notices of the American Mathematical Society", 
  volume = 35, 
  pages = "5--12"}

@article{lenstra-ecm,
  author = "Lenstra Jr., H.W.",
  year = 1987, 
  title = "Factoring integers with elliptic curves", 
  journal = "Ann. of Math.", 
  volume = 126, 
  pages = "649--673"}

@incollection{lenstra-survey,
  author = "Lenstra, A.K. and Lenstra Jr., H.W.", 
  year = 1990,
  title = "Algorithms in number theory", 
  editor = "van Leeuwen, J.", 
  booktitle = "Handbook of Theoretical Computer Science", 
  volume = "A", 
  publisher = "MIT Press/Elsevier", 
  address = "Amsterdam"}

@inproceedings{lenstra-nsf,
  author = "Lenstra, A.K. and Lenstra Jr., H.W. and Mannasse, M.S. and 
            Pollard, J.M.",
  year = 1990,
  title = "The number field sieve", 
  booktitle = "Proc. of the 22nd Annual ACM Symposium on the Theory of 
               Computing", 
  publisher = "ACM Press"}

@inproceedings{lenstra-ppmpqs,
  author = "Lenstra, A.K. and Manasse, M.S.", 
  year = 1991,
  title = "Factoring with two large primes", 
  booktitle = "Advances in Cryptology --- Eurocrypt '90", 
  pages = "72--82", 
  publisher = "Springer-Verlag",
  address = "Berlin"}

@manual{RFC-1113,
  author = "Linn, J.",
  year = 1989,
  month = "August",
  title = "RFC 1113: Privacy Enhancement for Internet Electronic Mail: Part {I}
           -- Message Encipherment and Authentication Procedures",
  organization = "Internet Activities Board"}

@manual{RFC-1115,
  author = "Linn, J.",
  year = 1989,
  month = "August",
  title = "RFC 1115: Privacy Enhancement for Internet Electronic Mail: Part
           {III} -- Algorithms, Modes and Identifiers",
  organization = "Internet Activities Board"}

@article{merkle-hellman,
  author = "Merkle, R.C. and Hellman, M.E.", 
  year = 1978,
  title = "Hiding information and signatures in trapdoor knapsacks", 
  journal = "IEEE Transactions on Information Theory", 
  volume = "IT-24",
  pages = "525--530"}

@article{merkle-hellman-multiple,
  author = "Merkle, R.C. and Hellman, M.E.",
  year = 1981,
  title = "On the security of multiple encryption",
  journal = "Communications of the ACM",
  volume = 24,
  pages = "465--467",
  month = "July"}

@article{messmer,
  author = "Messmer, E.", 
  year = 1992,
  title = "{NIST} stumbles on proposal for public-key encryption", 
  journal = "Network World", 
  volume = 9, 
  number = 30, 
  month = "July 27,"}

@inproceedings{miller,
  author = "Miller, V.S.", 
  year = 1986,
  title = "Use of elliptic curves in cryptography", 
  booktitle = "Advances in Cryptology --- Crypto '85", 
  pages = "417--426",
  publisher = "Springer-Verlag",
  address = "New York"}

@manual{des-77,
  author = "{National Bureau of Standards}",
  year = 1977,
  month = "January",
  title = "FIPS Publication 46: Announcing the Data Encryption Standard"}

@manual{des-modes,
  author = "{National Bureau of Standards}", 
  year = 1980,
  title = "FIPS Publication 81: {DES} Modes of Operation", 
  month = "December"}

@manual{des-88,
  author = "{National Bureau of Standards}",
  year = 1988,
  month = "January",
  title = "FIPS Publication 46-1: Data Encryption Standard"}

@manual{nist-dss,
  author = "{National Institute of Standards and Technology (NIST)}", 
  year = 1992,
  title = "Publication {XX}: Announcement and Specifications for a Digital
           Signature Standard (DSS)", 
  month = "August 19,"}

@manual{nist-shs,
  author = "{National Institute of Standards and Technology (NIST)}",
  year = 1992,
  title = "Publication {YY}: Announcement and Specifications for a 
           {Secure Hash Standard} (SHS)",
  month = "January 22,"}

@article{dss-discuss,
  author = "{National Institute of Standards and Technology (NIST)}",
  year = 1992,
  title = "The {Digital Signature Standard}, proposal and discussion",
  journal = "Communications of the ACM", 
  volume = 35, 
  number = 7,
  pages = "36--54", 
  month = "July"}

@book{computers-at-risk,
  author = "National Research Council, System Security Study Committee and
            others",
  year = 1991,
  title = "Computers at Risk: {Safe} Computing in the Electronic Age",
  publisher = "National Academy Press",
  address = "Washington, DC"}

@inproceedings{odlyzko,
  author = "Odlyzko, A.M.", 
  year = 1984,
  title = "Discrete logarithms in finite fields and their cryptographic 
           significance", 
  booktitle = "Advances in Cryptology --- Eurocrypt '84", 
  pages = "224--314", 
  publisher = "Springer-Verlag",
  address = "Berlin"}

@manual{oiw,
  author = "{OSI Implementors' Workshop}", 
  year = 1992,
  title = "Draft Working Implementation Agreements For Open Systems 
           Interconnection Protocols", 
  publisher = "NIST", 
  address = "Gaithersburg, Maryland",
  month = "June"}

@article{pohlig-hellman-dlog,
  author = "Pohlig, S.C. and Hellman, M.E.",
  year = 1978,
  title = "An improved algorithm for computing logarithms over $GF(p)$ and
           its cryptographic significance",
  journal = "IEEE Transactions on Information Theory",
  volume = "IT-24",
  pages = "106--110"}

@article{pollard1,
  author = "Pollard, J.", 
  year = 1974,
  title = "Theorems of factorization and primality testing", 
  journal = "Proc. Cambridge Philos. Soc.", 
  volume = 76, 
  pages = "521--528"}

@article{pollard2,
  author = "Pollard, J.", 
  year = 1975,
  title = "{Monte Carlo} method for factorization", 
  journal = "BIT", 
  volume = 15, 
  pages = "331--334"}

@techreport{rabin,
  author = "Rabin, M.O.", 
  year = 1979,
  title = "Digitalized signatures as intractable as factorization",
  institution = "MIT",
  number = "MIT/LCS/TR-212"}

@article{rsa,
  author = "Rivest, R.L. and A. Shamir and L. Adleman",
  year = 1978,
  month = "February",
  title = "A method for obtaining digital signatures and public-key
           cryptosystems",
  journal = "Communications of the ACM",
  volume = 21,
  number = 2,
  pages = "120--126"}

@inproceedings{rivest-md4,
  author = "Rivest, R.L", 
  year = 1991,
  title = "The {MD4} message digest algorithm", 
  booktitle = "Advances in Cryptology --- Crypto '90", 
  pages = "303--311", 
  publisher = "Springer-Verlag",
  address = "New York"}

@inproceedings{rivest-prob-prime,
  author = "Rivest, R.L.", 
  year = 1990,
  title = "Finding four million random primes", 
  booktitle = "Advances in Cryptology --- Crypto '90", 
  pages = "625--626",
  publisher = "Springer-Verlag", 
  address = "New York"}

@incollection{rivest-survey,
  author = "Rivest, R.L.", 
  year = 1990,
  title = "Cryptography",
  editor = "van Leeuwen, J.", 
  booktitle = "Handbook of Theoretical Computer Science", 
  volume = "A", 
  publisher = "MIT Press/Elsevier", 
  address = "Amsterdam"}

@manual{rfc-md5,
  author = "Rivest, R.L.",
  year = 1992,
  title = "{RFC} 1321: The {MD5 Message-Digest Algorithm}",
  month = "April",
  organization = "Internet Activities Board"}

@article{rivest-dss-response,
  author = "Rivest, R.L.", 
  year = 1992,
  title = "Response to {NIST}'s Proposal", 
  journal = "Communications of the ACM",
  volume = 35, 
  pages = "41--47", 
  month = "July"}

@manual{PKCS-5,
  author = "{RSA Data Security, Inc.}",
  year = 1991,
  month = "June",
  title = "PKCS \#5: Password-Based Encryption Standard",
  note = "Version 1.4"}

@book{computer-security-basics,
  author = "Russell, Deborah and G.T. Gangemi Sr.",
  year = 1991,
  title = "Computer Security Basics",
  publisher = "O'Reilly and Associates",
  address = "Sebastopol, CA"}

@inproceedings{schnorr,
  author = "Schnorr, C.P.", 
  year = 1990,
  title = "Efficient identification and signatures for smart cards", 
  booktitle = "Advances in Cryptology --- Crypto '89", 
  pages = "239--251", 
  publisher = "Springer-Verlag",
  address = "New York"}

@book{protecting-information,
  author = "Schweitzer, James A.",
  year = 1983,
  title = "Protection Information in the Electronic Workplace: A Guide for
           Managers",
  publisher = "Prentice-Hall",
  address = "Reston, VA"}

@article{silverman,
  author = "Silverman, R.D.", 
  year = 1987,
  title = "The multiple polynomial quadratic sieve", 
  journal = "Math. Comp.", 
  volume = 48, 
  pages = "329--339"}

@article{smid-des,
  author = "Smid, M.E. and Branstad, D.K.", 
  year = 1988,
  title = "The {Data Encryption Standard}: {Past} and future", 
  journal = "Proceedings of the IEEE", 
  volume = 76, 
  pages = "550--559"}

@inproceedings{smid,
  author = "Smid, M.E. and Branstad, D.K.", 
  year = 1993,
  title = "Response to comments on the {NIST} proposed {Digital Signature 
           Standard}", 
  booktitle = "Advances in Cryptology --- Crypto '92", 
  publisher = "Springer-Verlag", 
  note = "To appear"}

@manual{australia,
  author = "{Standards Australia}", 
  year = 1990,
  title = "AS 2805.6.5.3: Electronic Funds Transfer --- Key Management"}

@book{cuckoo's-egg,
  author = "Stoll, Cliff",
  year = 1989,
  title = "The Cuckoo's Egg: Tracing a Spy Through the Maze of Computer
           Espionage",
  publisher = "Doubleday",
  address = "New York"}

@article{wiener,
  author = "Wiener, M.J.", 
  year = 1990,
  title = "Cryptanalysis of short {RSA} secret exponents", 
  journal = "IEEE Trans. Information Theory", 
  volume = 36, 
  pages = "553--558"}






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com
Date: Tue, 6 Oct 92 17:44:27 PDT
To: uunet!shearson.com!pmetzger@uunet.UU.NET
Subject: Nuts & Acorns
In-Reply-To: <9210062244.AA07304@newsu.shearson.com>
Message-ID: <9210062358.AA08087@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


In the future I imagine several companies that seel public keys for
individuals.  Depending on how much risk of forgery you can tolerate,
you just buy an individuals public key from several of these
companies.  Then they must all collude to fool you.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 6 Oct 92 18:30:07 PDT
To: cypherpunks@toad.com
Subject: Nuts & Acorns
In-Reply-To: <9210062244.AA07304@newsu.shearson.com>
Message-ID: <9210070137.AA15880@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Perry:

>This does mean that a lot of the time until people have built up
>catenative assembleges of keys sufficent to form a "chain of trust"
>for unknown people that they will simply have to do without
>certification of the other person's identity. Isn't that the way life
>usually is, though?

In large part the electronic environment is already pseudonymous.  I
don't know most Usenet posters personally and never will.  I have no
need to personally verify their identities; in fact, I don't even want
to.

But for someone I'm going to deal with over a period of time, I do
want to make sure that it's the same person I'm dealing with each
time.  And if I never happen to meet this person face to face, or need
to know anything about this person as a physical being, so be it.  All
I really care about is persistence, not identity.

In the elctronic world, all you have are persistent pseudonyms.  Most
of them, true, are still linked to physical people, but there is no
particular reason why that need continue.

I think the changeover point will be this.  As soon as there is money
flowing through the networks which is tied only to pseudonyms and not
to physical people, then you'll see a _lot_ more virtual-only
identities.  When you can conduct business and get paid for it,
there's a big difference.  When some of your data has negotiable cash
value, you'll see privacy and security get *important*.

And most of these identities will have regular sounding names.
Handles, a la the underground, are more a mark of social identity than
of anonymity.  The best camouflage is not to draw attention to
yourself.  When most of the world is personal, look personal.  Who
will ever know?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Tue, 6 Oct 92 15:59:23 PDT
To: Tom.Jennings@f111.n125.z1.fidonet.org
Subject: Nuts & Acorns
In-Reply-To: <2654.2AD20C59@fidogate.FIDONET.ORG>
Message-ID: <9210062244.AA07304@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings)

>Not my worry. What I meant was, how do I know htat the keyfile I
>received from "John Smith @ net address" really is his, and not some
>faker. Short of physically getting key disks from someone face to
>face (flatly im-possible here), I don't know.

This is like asking "how do I get a bullet to stop in mid air and
launch itself back into the bullet casing in the breech of the gun".
You don't. Obviously, the only way to trust a key enough to certify it
is to actually get it in person and verify identity. This is often
impractical, but so what? If people want to communicate and the only
assurance your signature gives them is that you got a copy of the keys
by email, they might as well just email each other they keys and live
knowing that the messages they are sending are to possibly
non-securely identified people. Signed introduced keys should be
reserved for times when you can actually add real information by
claiming the key is really owned by the person who claims it.

This does mean that a lot of the time until people have built up
catenative assembleges of keys sufficent to form a "chain of trust"
for unknown people that they will simply have to do without
certification of the other person's identity. Isn't that the way life
usually is, though?

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Tue, 6 Oct 92 22:34:13 PDT
To: Eric Hughes <hughes@soda.berkeley.edu>
Subject: Re: Nuts & Acorns
In-Reply-To: <9210070137.AA15880@soda.berkeley.edu>
Message-ID: <9210070541.AA23855@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>In the elctronic world, all you have are persistent pseudonyms.  Most
>of them, true, are still linked to physical people, but there is no
>particular reason why that need continue.

Instead of thinking of keys as things belonging to people, we can think of
people as things associated with keys.  In fact, we just need to shift the
focus to be entirely on the keys, and leave the people out of it.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Wed, 7 Oct 92 16:46:07 PDT
To: cypherpunks@toad.com
Subject: re: introducers
Message-ID: <2715.2AD37337@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> Detection of tampering is plenty good enough, I think, for 
 U> a _network_ policy of key distribution.  For most people, 
 U> it will work fine.

I guess I had to come at this from the backside. You are right.
Accepting keys over the network will provide reasonably well-sealed
envelopes. It won't provide notarized, hand-delivered security, but
that's not what's needed *usually*.

 U> For personal use, for people I know, I'm going to rely on 
 U> personally
 U> exchanged keys.

Exactly.

 * Origin: World Power Systems / FidoNews  (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Thu, 8 Oct 92 01:04:18 PDT
To: cypherpunks@toad.com
Subject: Hammill on public key
Message-ID: <1439@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


  FROM CROSSBOWS TO CRYPTOGRAPHY:  THWARTING THE STATE VIA
                     TECHNOLOGY
 
  Given at the Future of Freedom Conference, November 1987
 
 
     You   know,   technology--and   particularly   computer
technology--has often gotten a bad rap in  Libertarian  cir-
cles.  We tend to think of Orwell's 1984, or Terry Gilliam's
Brazil,  or  the  proximity  detectors keeping East Berlin's
slave/citizens on their own side of the border, or  the  so-
phisticated  bugging  devices  Nixon used to harass those on
his "enemies list."  Or, we recognize that for the price  of
a  ticket  on  the Concorde we can fly at twice the speed of
sound, but only if we first walk thru a magnetometer run  by
a  government  policeman, and permit him to paw thru our be-
longings if it beeps.
 
     But I think that mind-set is a mistake.   Before  there
were cattle prods, governments tortured their prisoners with
clubs  and  rubber  hoses.    Before  there  were lasers for
eavesdropping, governments used binoculars and  lip-readers.
Though  government certainly uses technology to oppress, the
evil lies not in the tools but in the wielder of the tools.
 
     In fact, technology represents one of the most  promis-
ing  avenues  available  for  re-capturing our freedoms from
those who have stolen them.  By its very nature,  it  favors
the  bright  (who can put it to use) over the dull (who can-
not).  It favors the adaptable (who are  quick  to  see  the
merit  of  the  new(  over  the sluggish (who cling to time-
tested ways).  And what two better words are  there  to  de-
scribe government bureaucracy than "dull" and "sluggish"?
 
     One  of  the  clearest,  classic triumphs of technology
over tyranny I see is  the  invention  of  the  man-portable
crossbow.   With it, an untrained peasant could now reliably
and lethally engage a target out to  fifty  meters--even  if
that  target  were  a mounted, chain-mailed knight.  (Unlike
the longbow, which, admittedly was more powerful, and  could
get  off  more shots per unit time, the crossbow required no
formal training to utilize.   Whereas the  longbow  required
elaborate  visual,  tactile  and kinesthetic coordination to
achieve any degree of accuracy, the wielder  of  a  crossbow
could simply put the weapon to his shoulder, sight along the
arrow  itself, and be reasonably assured of hitting his tar-
get.)
 
     Moreover, since just about  the  only  mounted  knights
likely  to  visit  your  average peasant would be government
soldiers and tax collectors, the utility of the  device  was
plain:    With it, the common rabble could defend themselves
not only against one another, but against their governmental
masters.   It was the  medieval  equivalent  of  the  armor-
piercing  bullet,  and, consequently, kings and priests (the
medieval equivalent of a  Bureau  of  Alcohol,  Tobacco  and
Crossbows)  threatened  death  and  excommunication, respec-
tively, for its unlawful possession.
 
     Looking at later developments, we  see  how  technology
like  the  firearm--particularly the repeating rifle and the
handgun, later followed by the Gatling gun and more advanced
machine guns--radically altered the balance of interpersonal
and inter-group power.  Not without reason was the Colt  .45
called "the equalizer."  A frail dance-hall hostess with one
in  her  possession  was  now  fully able to protect herself
against the brawniest roughneck in any saloon.    Advertise-
ments  for  the period also reflect the merchandising of the
repeating cartridge  rifle  by  declaring  that  "a  man  on
horseback,  armed with one of these rifles, simply cannot be
captured."  And, as long as his captors  were  relying  upon
flintlocks  or  single-shot rifles, the quote is doubtless a
true one.
 
     Updating now to  the  present,  the  public-key  cipher
(with  a  personal  computer to run it) represents an equiv-
alent quantum leap--in a defensive weapon.    Not  only  can
such  a technique be used to protect sensitive data in one's
own possession, but it can also permit two strangers to  ex-
change   information   over   an   insecure   communications
channel--a  wiretapped   phone   line,   for   example,   or
skywriting, for that matter)--without ever having previously
met  to  exchange cipher keys.   With a thousand-dollar com-
puter, you can create a cipher that  a  multi-megabuck  CRAY
X-MP  can't  crack in a year.  Within a few years, it should
be economically feasible to similarly encrypt voice communi-
cations; soon after that, full-color digitized video images.
Technology will not only have made wiretapping obsolete,  it
will  have  totally demolished government's control over in-
formation transfer.
 
     I'd like to take just a moment to sketch the  mathemat-
ics  which makes this principle possible.  This algorithm is
called the RSA algorithm, after Rivest, Shamir, and  Adleman
who  jointly created it.  Its security derives from the fact
that, if a very large number is  the  product  of  two  very
large  primes,  then it is extremely difficult to obtain the
two prime factors from analysis  of  their  product.    "Ex-
tremely"  in  the  sense that if primes  p  and  q  have 100
digits apiece, then their 200-digit product cannot  in  gen-
eral be factored in less than 100 years by the most powerful
computer now in existence.
 
     The  "public" part of the key consists of (1) the prod-
uct  pq  of the two large primes p and q, and (2)  one  fac-
tor,  call it  x  , of the product  xy  where  xy = {(p-1) *
(q-1) + 1}.  The "private" part of the key consists  of  the
other factor  y.
 
     Each  block of the text to be encrypted is first turned
into an integer--either by using ASCII,  or  even  a  simple
A=01,  B=02,  C=03, ... , Z=26 representation.  This integer
is then raised to the power  x (modulo pq) and the resulting
integer is then sent as the encrypted message.  The receiver
decrypts by taking this integer to the  (secret)  power    y
(modulo  pq).  It can be shown that this process will always
yield the original number started with.
 
     What makes this a groundbreaking development,  and  why
it  is  called  "public-key"  cryptography,"  is  that I can
openly publish the product  pq and the number   x   ,  while
keeping  secret  the number  y  --so that anyone can send me
an encrypted message, namely
                       x
                     a    (mod pq)  ,
but only I can recover the original message  a  , by  taking
what  they  send, raising it to the power  y  and taking the
result (mod pq).  The risky step (meeting to exchange cipher
keys) has been eliminated.  So people who may not even trust
each other enough to want to meet, may  still  reliably  ex-
change  encrypted  messages--each  party having selected and
disseminated his own  pq  and his  x  ,   while  maintaining
the secrecy of his own  y.
 
     Another benefit of this scheme is the notion of a "dig-
ital signature," to enable one to authenticate the source of
a given message.  Normally, if I want to send you a message,
I raise my plaintext  a  to your x and take the result  (mod
your pq)  and send that.
 
    However,  if in my message, I take the plaintext  a and
raise it to my (secret) power  y  , take the result  (mod my
pq), then raise that result to your x   (mod  your  pq)  and
send this, then even after you have normally "decrypted" the
message,  it  will still look like garbage.  However, if you
then raise it to my public power x   , and take  the  result
(mod  my public pq  ), so you will not only recover the ori-
ginal plaintext message, but you will know that no one but I
could have sent it to you (since no one else knows my secret
y).
 
     And these are the very concerns by the way that are to-
day tormenting the Soviet Union about the whole question  of
personal  computers.    On the one hand, they recognize that
American schoolchildren are right now growing up  with  com-
puters  as commonplace as sliderules used to be--more so, in
fact, because there are things computers can do  which  will
interest  (and instruct) 3- and 4-year-olds.  And it is pre-
cisely these students who one generation hence will be going
head-to-head against their Soviet  counterparts.    For  the
Soviets  to  hold  back might be a suicidal as continuing to
teach swordsmanship  while  your  adversaries  are  learning
ballistics.    On  the  other hand, whatever else a personal
computer may be, it is also an exquisitely efficient copying
machine--a floppy disk will hold upwards of 50,000 words  of
text,  and  can  be  copied in a couple of minutes.  If this
weren't threatening enough, the computer that  performs  the
copy  can also encrypt the data in a fashion that is all but
unbreakable.  Remember that in Soviet society  publicly  ac-
cessible  Xerox  machines are unknown.   (The relatively few
copying machines in existence  are  controlled  more  inten-
sively than machine guns are in the United States.)
 
     Now  the  "conservative" position is that we should not
sell these computers to the Soviets, because they could  use
them  in weapons systems.  The "liberal" position is that we
should sell them, in  the  interests  of  mutual  trade  and
cooperation--and  anyway,  if  we don't make the sale, there
will certainly be some other nation willing to.
 
     For my part, I'm ready to suggest that the  Libertarian
position should be to give them to the Soviets for free, and
if  necessary, make them take them . . . and if that doesn't
work load up an SR-71  Blackbird  and  air  drop  them  over
Moscow in the middle of the night.  Paid for by private sub-
scription, of course, not taxation . . . I confess that this
is not a position that has gained much support among members
of  the conventional left-right political spectrum, but, af-
ter all, in the words of one of Illuminatus's characters, we
are political non-Euclideans:   The shortest distance  to  a
particular  goal may not look anything like what most people
would consider a "straight line."    Taking  a  long  enough
world-view,  it is arguable that breaking the Soviet govern-
ment monopoly on information transfer could better  lead  to
the enfeeblement and, indeed, to the ultimate dissolution of
the Soviet empire than would the production of another dozen
missiles aimed at Moscow.
 
     But  there's  the rub:  A "long enough" world view does
suggest that the evil, the oppressive, the coercive and  the
simply  stupid  will "get what they deserve," but what's not
immediately clear is how the rest of  us  can  escape  being
killed, enslaved, or pauperized in the process.
 
    When  the  liberals and other collectivists began to at-
tack freedom, they possessed a reasonably  stable,  healthy,
functioning economy, and almost unlimited time to proceed to
hamstring   and   dismantle  it.    A  policy  of  political
gradualism was at least  conceivable.    But  now,  we  have
patchwork  crazy-quilt  economy held together by baling wire
and spit.  The state not only taxes us to  "feed  the  poor"
while also inducing farmers to slaughter milk cows and drive
up food prices--it then simultaneously turns around and sub-
sidizes research into agricultural chemicals designed to in-
crease  yields of milk from the cows left alive.  Or witness
the fact that a decline in the price of oil is considered as
potentially frightening as a comparable increase a few years
ago.  When the price went up,  we  were  told,  the  economy
risked  collapse for for want of energy.  The price increase
was called the "moral equivalent of war" and the Feds  swung
into  action.    For the first time in American history, the
speed at which you drive your car to work in the morning be-
came an issue of Federal concern.   Now, when the  price  of
oil  drops, again we risk problems, this time because Ameri-
can oil companies and Third World  basket-case  nations  who
sell  oil  may  not  be  able to ever pay their debts to our
grossly over-extended banks.  The suggested panacea is  that
government  should now re-raise the oil prices that OPEC has
lowered, via a new oil tax.  Since the government is seeking
to raise oil prices to about the same extent  as  OPEC  did,
what  can we call this except the "moral equivalent of civil
war--the government against its own people?"
 
     And, classically, in international trade, can you imag-
ine any entity in the world except  a  government  going  to
court  claiming  that  a  vendor  was  selling  it goods too
cheaply and demanding not only that that naughty  vendor  be
compelled by the court to raise its prices, but also that it
be punished for the act of lowering them in the first place?
 
     So  while the statists could afford to take a couple of
hundred years to trash our  economy  and  our  liberties--we
certainly  cannot  count  on  having an equivalent period of
stability in which to reclaim them.   I contend  that  there
exists  almost  a  "black  hole"  effect in the evolution of
nation-states just as in the evolution of stars.  Once free-
dom contracts beyond a certain  minimum  extent,  the  state
warps  the fabric of the political continuum about itself to
the degree that subsequent re-emergence of  freedom  becomes
all but impossible.  A good illustration of this can be seen
in the area of so-called "welfare" payments.  When those who
sup  at the public trough outnumber (and thus outvote) those
whose taxes must replenish the trough,  then  what  possible
choice has a democracy but to perpetuate and expand the tak-
ing  from  the few for the unearned benefit of the many?  Go
down to the nearest "welfare" office, find just  two  people
on  the dole . . . and recognize that between them they form
a voting bloc that can forever outvote you on  the  question
of who owns your life--and the fruits of your life's labor.
 
     So essentially those who love liberty need an "edge" of
some  sort  if  we're ultimately going to prevail.  We obvi-
ously  can't  use  the  altruists'  "other-directedness"  of
"work,  slave, suffer, sacrifice, so that next generation of
a billion random strangers can  live  in  a  better  world."
Recognize  that, however immoral such an appeal might be, it
is nonetheless an extremely powerful one in today's culture.
If you can convince  people  to  work  energetically  for  a
"cause," caring only enough for their personal welfare so as
to  remain  alive  enough  and  healthy  enough  to continue
working--then you have a truly massive reservoir  of  energy
to draw from.  Equally clearly, this is just the sort of ap-
peal which tautologically cannot be utilized for egoistic or
libertarian goals.  If I were to stand up before you tonight
and say something like, "Listen, follow me as I enunciate my
noble "cause," contribute your money to support the "cause,"
give  up  your  free  time  to  work for the "cause," strive
selflessly to bring it about, and then (after you  and  your
children are dead) maybe your children's children will actu-
ally  live under egoism"--you'd all think I'd gone mad.  And
of course you'd be right.  Because the point I'm  trying  to
make is that libertarianism and/or egoism will be spread if,
when, and as, individual libertarians and/or egoists find it
profitable and/or enjoyable to do so.    And  probably  only
then.
 
     While I certainly do not disparage the concept of poli-
tical  action, I don't believe that it is the only, nor even
necessarily the most cost-effective path  toward  increasing
freedom  in  our time.  Consider that, for a fraction of the
investment in time, money and effort I might expend in  try-
ing  to  convince  the  state to abolish wiretapping and all
forms of censorship--I can teach every libertarian who's in-
terested  how  to   use   cryptography   to   abolish   them
unilaterally.
 
     There  is  a  maxim--a proverb--generally attributed to
the Eskimoes, which very likely most Libertarians  have  al-
ready  heard.    And while you likely would not quarrel with
the saying, you might well feel that you've heard  it  often
enough already, and that it has nothing further to teach us,
and moreover, that maybe you're even tired of hearing it.  I
shall therefore repeat it now:
 
     If you give a man a fish, the saying runs, you feed him
for a day.  But if you teach a man how to fish, you feed him
for a lifetime.
 
     Your exposure to the quote was probably in some sort of
a  "workfare"  vs.  "welfare"  context;  namely, that if you
genuinely wish to help someone in need, you should teach him
how to earn his sustenance, not simply how to  beg  for  it.
And of course this is true, if only because the next time he
is hungry, there might not be anybody around willing or even
able to give him a fish, whereas with the information on how
to fish, he is completely self sufficient.
 
     But  I  submit  that this exhausts only the first order
content of the quote, and if there were nothing  further  to
glean  from  it,  I would have wasted your time by citing it
again.  After all, it seems to have almost a crypto-altruist
slant, as though to imply that we should structure  our  ac-
tivities  so  as  to  maximize  the  benefits to such hungry
beggars as we may encounter.
 
     But consider:
 
     Suppose this Eskimo doesn't know how to  fish,  but  he
does  know  how  to hunt walruses.   You, on the other hand,
have often gone hungry while traveling thru  walrus  country
because  you  had  no idea how to catch the damn things, and
they ate most of the fish you could catch.  And now  suppose
the  two  of  you  decide to exchange information, bartering
fishing knowledge for hunting knowledge.   Well,  the  first
thing  to  observe  is  that  a  transaction  of  this  type
categorically and unambiguously refutes the Marxist  premise
that  every  trade  must  have a "winner" and a "loser;" the
idea that if one person gains, it must necessarily be at the
"expense" of another person who loses.  Clearly, under  this
scenario, such is not the case.  Each party has gained some-
thing  he  did  not have before, and neither has been dimin-
ished in any way.  When it comes to exchange of  information
(rather  than material objects) life is no longer a zero-sum
game.  This is an extremely powerful notion.   The  "law  of
diminishing   returns,"   the  "first  and  second  laws  of
thermodynamics"--all those "laws" which constrain our possi-
bilities in other contexts--no longer bind us!   Now  that's
anarchy!
 
     Or  consider  another possibility:  Suppose this hungry
Eskimo never learned  to  fish  because  the  ruler  of  his
nation-state    had  decreed fishing illegal.   Because fish
contain dangerous tiny bones, and sometimes sharp spines, he
tells us, the state has decreed that their  consumption--and
even  their  possession--are  too  hazardous to the people's
health to be permitted . . . even by knowledgeable,  willing
adults.   Perhaps it is because citizens' bodies are thought
to be government property, and therefore it is the  function
of the state to punish those who improperly care for govern-
ment  property.    Or perhaps it is because the state gener-
ously extends to competent adults the "benefits" it provides
to children and to the mentally ill:  namely,  a  full-time,
all-pervasive supervisory conservatorship--so that they need
not  trouble  themselves  with making choices about behavior
thought physically risky or morally "naughty."  But, in  any
case,  you  stare stupefied, while your Eskimo informant re-
lates how this law is taken so seriously that  a  friend  of
his was recently imprisoned for years for the crime of "pos-
session of nine ounces of trout with intent to distribute."
 
     Now  you  may  conclude  that  a society so grotesquely
oppressive as to enforce a law of this  type  is  simply  an
affront to the dignity of all human beings.  You may go far-
ther  and  decide to commit some portion of your discretion-
ary, recreational time specifically to the task of thwarting
this tyrant's goal.  (Your rationale may be "altruistic"  in
the   sense   of  wanting  to  liberate  the  oppressed,  or
"egoistic" in the sense of  proving  you  can  outsmart  the
oppressor--or  very likely some combination of these or per-
haps even other motives.)
 
     But, since you have zero desire to become a  martyr  to
your "cause," you're not about to mount a military campaign,
or  even try to run a boatload of fish through the blockade.
However, it is here that technology--and in  particular  in-
formation technology--can multiply your efficacy literally a
hundredfold.    I say "literally," because for a fraction of
the effort (and virtually none of  the  risk)  attendant  to
smuggling in a hundred fish, you can quite readily produce a
hundred  Xerox copies of fishing instructions.  (If the tar-
geted government, like present-day America, at least permits
open  discussion  of  topics  whose  implementation  is  re-
stricted,  then that should suffice.  But, if the government
attempts to suppress the flow of information as  well,  then
you will have to take a little more effort and perhaps write
your  fishing manual on a floppy disk encrypted according to
your mythical Eskimo's public-key parameters.  But as far as
increasing real-world access to fish you have  made  genuine
nonzero  headway--which  may  continue to snowball as others
re-disseminate the information you have provided.   And  you
have not had to waste any of your time trying to convert id-
eological  adversaries, or even trying to win over the unde-
cided.  Recall Harry Browne's dictum  from  "Freedom  in  an
Unfree World" that the success of any endeavor is in general
inversely proportional to the number of people whose persua-
sion is necessary to its fulfilment.
 
     If  you  look  at  history, you cannot deny that it has
been dramatically shaped by men with names like  Washington,
Lincoln,  .  .  .  Nixon  .  . . Marcos . . . Duvalier . . .
Khadaffi . . .  and their ilk.  But it has also been  shaped
by  people with names like Edison, Curie, Marconi, Tesla and
Wozniak.  And this latter shaping has been at least as  per-
vasive, and not nearly so bloody.
 
     And  that's  where  I'm  trying  to  take The LiberTech
Project.  Rather than beseeching the state to please not en-
slave, plunder or constrain us, I propose a libertarian net-
work spreading  the  technologies  by  which  we  may  seize
freedom for ourselves.
 
     But here we must be a bit careful.  While it is not (at
present)  illegal  to  encrypt  information  when government
wants to spy on you, there is no guarantee of what  the  fu-
ture  may hold.  There have been bills introduced, for exam-
ple, which would have made it a crime  to  wear  body  armor
when government wants to shoot you.  That is, if you were to
commit certain crimes while wearing a Kevlar vest, then that
fact  would  constitute a separate federal crime of its own.
This law to my knowledge has not passed . . . yet . . .  but
it does indicate how government thinks.
 
     Other  technological  applications,  however, do indeed
pose legal risks.  We recognize, for  example,  that  anyone
who  helped a pre-Civil War slave escape on the "underground
railroad" was making a clearly illegal use of technology--as
the sovereign government of the United States of America  at
that time found the buying and selling of human beings quite
as  acceptable  as  the buying and selling of cattle.  Simi-
larly, during Prohibition, anyone who used  his  bathtub  to
ferment  yeast and sugar into the illegal psychoactive drug,
alcohol--the controlled substance, wine--was using  technol-
ogy  in a way that could get him shot dead by federal agents
for his "crime"--unfortunately not to be  restored  to  life
when  Congress  reversed itself and re-permitted use of this
drug.
 
     So . . . to quote a former President,  un-indicted  co-
conspirator  and pardoned felon . . . "Let me make one thing
perfectly clear:"  The LiberTech Project does not  advocate,
participate  in, or conspire in the violation of any law--no
matter how oppressive,  unconstitutional  or  simply  stupid
such  law may be.  It does engage in description (for educa-
tional and informational  purposes  only)  of  technological
processes,  and some of these processes (like flying a plane
or manufacturing a firearm) may well require appropriate li-
censing to perform legally.    Fortunately,  no  license  is
needed  for  the  distribution or receipt of information it-
self.
 
     So, the next time you look at the political  scene  and
despair,  thinking,  "Well,  if 51% of the nation and 51% of
this State, and 51% of this city have  to  turn  Libertarian
before  I'll  be  free,  then  somebody might as well cut my
goddamn throat now, and put me out of my  misery"--recognize
that  such  is not the case.  There exist ways to make your-
self free.
 
     If you wish to explore such techniques via the Project,
you are welcome to give me your name and address--or a  fake
name  and  mail  drop, for that matter--and you'll go on the
mailing list for my erratically-published newsletter.    Any
friends  or acquaintances whom you think would be interested
are welcome as well.  I'm not even asking for stamped  self-
addressed envelopes, since my printer can handle mailing la-
bels and actual postage costs are down in the noise compared
with  the  other  efforts  in getting an issue out.   If you
should have an idea to share, or even a  useful  product  to
plug,  I'll be glad to have you write it up for publication.
Even if you want to be the proverbial "free rider" and  just
benefit  from  what others contribute--you're still welcome:
Everything will be public domain; feel free to  copy  it  or
give it away (or sell it, for that matter, 'cause if you can
get  money  for  it while I'm taking full-page ads trying to
give it away, you're certainly entitled to  your  capitalist
profit . . .)  Anyway, every application of these principles
should make the world just a little freer, and I'm certainly
willing to underwrite that, at least for the forseeable  fu-
ture.
 
     I  will leave you with one final thought:  If you don't
learn how to beat your plowshares into  swords  before  they
outlaw  swords,  then you sure as HELL ought to learn before
they outlaw plowshares too.
 
                                       --Chuck Hammill
 
                                 THE LIBERTECH PROJECT
                                 3194 Queensbury Drive
                               Los Angeles, California
                                                 90064
                                          310-836-4157

[The above LiberTech address was updated June 1992, with the
 permission of Chuck Hammill, by:

Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMIX: RWHITAKER
Board member, Extropy Institute (ExI)
[.sig revised 11 September 1992    ///    Send mail to eternity node]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no
pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI
lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR
tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j
by51az4=
=LOCL
-----END PGP PUBLIC KEY BLOCK-----






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hughes (Eric Hughes)
Date: Thu, 8 Oct 92 08:41:35 PDT
To: whitaker@eternity.demon.co.uk
Subject: Subscribe
In-Reply-To: <1480@eternity.demon.co.uk>
Message-ID: <9210081541.AA03134@toad.com>
MIME-Version: 1.0
Content-Type: text/plain



You are subscribed.

Next time, please use the cypherpunks-request@toad.com address for
administrative matters.  Tell your friends this as well.  Your request
got sent out to the whole list, not a tragedy, but an annoyance.

I met Max More at a party about a month ago.  I suspect he might be
interested in the list.  Do you have an e-mail address for him?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 8 Oct 92 08:57:23 PDT
To: cypherpunks@toad.com
Subject: Subscriptions, etc.
In-Reply-To: <9210081541.AA03134@toad.com>
Message-ID: <9210081604.AA15870@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Yow! I'm a hypocrite!

Now _I_ forgot to look at the reply line.  Damn.

Diligence, diligence.

--------------------------------------------

In other news, the list membership is up to 60 people and one local
newsgroup gateway.  I have five more to add, some of whose addresses I
have to find out.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Thu, 8 Oct 92 18:48:59 PDT
To: cypherpunks@toad.com
Subject: re: Subscribe
Message-ID: <2733.2AD49634@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



My public key.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQBNAirHIV8AAAECAOE6hyvBZUslVOgi12u6d7/6yMIXX4aKIRcfV3wa/ysHl+ul
d4agC1YW+YimYeA+/bXOBxH/Y/KRzT/tLvUlcRcABRG0MVRvbSBKZW5uaW5ncyA8
dG9takBmaWRvc3cuZmlkb25ldC5vcmcsIDE6MTI1LzExMT4=
=dADc
-----END PGP PUBLIC KEY BLOCK-----


My public key ring, signed with my secret key:

-----BEGIN PGP MESSAGE-----
Version: 2.0

owF1l3VU0/v/xzeGtCBwQUJ0ICI5OqUbJEYb1IQx5tgGYwMpBamBpNJggAEoKiAq
HVe6Q0pC8tKO0tH8JlcO9/zO+f7zOe/P+4/3eb8fz+erogA2VKcAol9lmDs0ViA/
L3mdBQIDmKkA47t9zTtBybMxWgRHMzFr/pgLHXIsVYQW+yWb94wbYdAYS7nw5gXk
tzbBbHO1QSuNTpl6zzKU6rVWOs0L/b1mEemAWCrRwlAHAABIDWgwlYrbWbw2XoaW
b3zZCgv3S3HuqqopxwsyjKNvnaK98dRo/hV6Ox7arP/466UMMPCHYzTqTKh1rbiS
1ZsgvHKm2lZ1yF6go9O90lO5hqdz74QuG6b8CnexkThg53Mdluod7XCds1a/WBp7
Xya6xBFoGMOAee6kzK4bNk3aXWtAmQNOsRYCtUpkLQne3nAPD7AeBGznjsTDUHAc
WNX3z0oTjofjMEi8H8QVjsZiIC5YCAGlXggERf1GdEb0q7TgCSIoBVHmkotkeXv7
wBdZ+vc9HTNJVPM5qilvhegDL2Z7KQqkrg2KqvY62YPiIgH0LUX1U2w40Y0H7dkP
6IQU8pEIZ2u+QmBkOsCUSrQCLkWhRAWoFd3nfF4WwjkvsHSRCOBxjHXGkt84zP0z
3E4S/fmqExOsl8b8/iwnQ3WehZ0f3oKXv9ico4CslM61J1fdzp1ADzjFXgjUKxHV
xsFcwToQsKmLDgyH9wOruilIK0Iw0jLyEH9piBvSFYuB4yFYHOI/j+s1en7yuBYG
4KHRaiu3KqlnBPkWqz/et99F20etH4q0Vfhp6qzazcxcSQph6Cvc1aIKK+zVi6vJ
mnip4yXJHMydlhEbQtXLPdp99DiKBT69wx5ZoC290jPdNzgivHs0yK4l/nzkfq0f
1BLPyS17+2Yo4m6DWNncJsekp2Yy6Lai6an4GOI9Uufyt6oJDn5W9zjaJNvUWFTz
5f26W/QMjJy9mbJBqtG1+yCSfOD7gyIFe9ZT2RduNXjs3ezVZTOSihVLHI+9d7ND
QHaXptgqKk1Hudju+5EFKHCs3GG+GPBVCNiCgMRgKGwU5eWlKHCkFChwNP8XHNUT
OGZtwD0GI70XrQ9scaP9V1Bhwqki38qz/OueQwMg/PxpyQJVwj+5lLkftublBGrL
B8jTaESJNXgtMcdPU13YNCMWddocUuBEAZJ/H909OIxGK1l6X824DgQWeIMO9Ssz
B+x+yVuwfiTr1vYvGrVofdLjWYmWHJHJA9pn7yTowWSVW7q7aiIm74w4zOEGdPvq
cVlgj/vJXjrL5c/O1PCeU7s1J/B1FdgXdCCfwOv9md592Tk9eVcNkkd+I7/PBR9m
nQ27cu7Sd+OQIMIAW4MgZ3HlpOE9Sc1oVMACDJNSCAw/0q1D4uBItw8yzSNTRVVW
lyzWIxhXUMMLLEB3wdB8odektdZtldT7KtzskVy2LORr6UK6XdyY6UJrZjXjZjnH
tH3hUO2FEV5pwbJgIjzaN2YoyT863BMsmPlB5FbllWdmQcm8HDFUdNl5jz+sqJKt
1Z8YM9x8+KLQwdwZWmwqnHhM5Y9uwjruOKQ3HuvpTglZ7X8DV1pFVlFOUlruf6oG
OlHtLjfw0PLjZG/BCzK1SI1vhjiPNnTZznJmse6cOACATdLs5ZG468ZB4Js+75TK
XrTchGTiYY6XPI1hSssa5705G1GkQ3+iWodLK5fdzFjRp9KLQKBAHOhAnriXXJQy
FVIkN43v9napcZDl8y8oXj6IW9mj3mfJnmWEpRo79F+OGzdee62QCqEb7is3LKo5
WLxjvWZ0ge5qOAF7jb0iSymCdlguFyhG6nFWJnF2pEz3Y+Yrg/9Cv3vtzvH99kWR
LsyZogpGUaXxlehAKV2mZ1E9MpWYSzZ2YW8oqh1fTVHsxFDdAGpAiBqogyeyhm9W
newGI52/mRrTCHwwHttXWkTeY+F+5/bMGPDWwVryS/reEoeDFOOFpyy58ULzLP4s
aqgLS09Sc+AVfTg9dpsuZkHHAwdnSY2cH60/eCdo32KCmdBXP2x0SqNyBoP4Ncf2
y4Q0xi8h9MY5tRRrt00ULeEPH/g9gm8eG6oRnnhkqOokL5Uh1Wx7bbnlgc2R+tux
A2MDlQ5Fm9+5C8jNYtSTgRsLL/VmGBwjuvQ1Enerrpfq5IARUjliVfiVImx2z/6D
zDqJnzwrUn8F8U7Evghd3rE0RQwtrxdDYu/+uO2J3resQRh64qM3LjcCWXP753Oc
xy3+ubuE8D0W7I+h5AyugqEwFzgYfPNfH8kogFURKE/KlqabjAIEQ9n7/+nS4chc
/2JuYTzBvC5IDUhq5jHkNs1ZbJ8dDOYWncgvzX2/edjrbUy/sYDAF4qsVCjEx7IW
uZ0TNVdX6TCydOeSJeQ2xRv7OFQvZpIj6ek8BPGetr4IuXq6r9PyXMvYxz5EIYc1
jR+wxzf621YCnFFXF06nQocYM4WfJT4ZSOUaXco73A7IFYfSWfON24h/OHLAke+b
9dJPfG9fADzUbD9dmcokouzeHcA8uiLxmH4f6VbBa3ul+cKGrRT1evFHTvbMT+rD
aiUp4irCTSv1xb8mmk/jsuzvWNIl2xqfQx6n8sJa6JGCn5QDV6inTilsxRn/uPcQ
LFYM7rPOiN8Y1iaJlSWNJKQMvtbf1x1fHP7UuMY2FJNlzy6VuPD+RgmmQ2HwYRnt
1qFY2VC7W14InkaEkSVg8TM7m/irMy8QdnFSbGPqp8O4thAlbGPNz28R8okt2XxV
5+832PRLTKrg6NzEDBDLGeC6PwqKaeFuwzFgAwjYBI7B+4OFTfTMrG+Arcz1re20
LPUkdPVs9UzMoaaUXZGTrNAkmH9CR8mXCjAAEe8dbGJY5rKaDsgwebcmEXm13yCn
9kuW7YKUbZcd5IUmKS/ANjR7dUQsq3bepF3NNfBCxCgHFxHjfy07lJPumA56XfyI
TlF08KdZVsBTr0QBnfk6zkDlUM27zx0jpHbFndmIKx+fxbjVMefPaIfS3AYZvawr
+xiUKfrQwZ+upF/UZxgU8zJl7N1hqwNHZO66S0Fvrat/EO3CbE5jT8H6JHeK5t68
jNWzXzx1uVKK7MgvX6YDhQdYEi0TSNuG7e+nCOPMhwgy4xEdQIk41B3pgfQEW0LA
N5BoNByHhv0ud544f01vGAIOcUG4QgguMBwE7kqgJE2qKEDSka+VgCe+FssHbXV+
oq66Y0OqrOpFJwewcHtIHeb+lW/jAZZ1fGdVGGILlZR5sXyIETX3j5ogXxp6Fz8A
SI7XV88Mbbhi9tXZqMwiSO5UCHcjv555jDIdaYs6dUlgZZ5/IIMgJI0/97M0hTtn
kXpHS9L3Llogw0YtIEKCY8yfOFjB0q8E5wpxumF1ktiwlnKbrYCQ2DmBYSBQeZca
UIPfzekEvjArlVkXfjPK2/7ImKUJo2v9LkXcqT1jiGSqv/OrsJLQMa87t90DzZE3
M83vfGJEjs64+lgozqYaVfz0nz7ZzWQkEzlpLXaGND2HnWicumZHY5JU5VAbnfO5
qev6za2e5zK0slMO5qUyFqf7P+7HH8b0VVusZ7cVpN0CUygfCe9Rl34kfOvo63Wp
5lzJBvcGtLYoaQvW4br0cmYSH2OUWrKjcfPsT7OMei5L1I2w1UrPDoWA/a3bSCN7
ePnk8+Q4JpVnAUFljz4rMAkTeVmrUfRjWue/LQRV7psqI091E1t6t4ggpXKVYDF9
6A1G5nBhbAIkRSUyabE7ZzsPfEzlj/CXKe0fBoUFm1C+cG9KSwsGq3r8WWu6+SIh
BB8YBONB0Rzwhyx6PeHYPEDg32dBh56kM6ba98TNjJ7SQh4u9rguw/TPbwIOB9+0
sc6+lvoSxpbgJ2DEs9GU9vXMd+dc26Ud2SeiDRq3yltFZPYtOCDcDlJBFQ+TJ/Pq
eLZpAttoJYgCAAM+K/ox4zNCC2L3OnjoO05/CzAK5jQ3cX6Y5tkW5Vy1Sp+2VBB3
TaF80vCHz5djsgEyOUdkB9A6Ff2eHHnfHZLnyAmu6JT64F/0nQ/DtDuuu0+xYq/U
+PCThgaejv6T9cuZKWm3uwT9j4ENbDV7lc8SgTx758O396XVF0PFx5I81MJ+8LDE
oZvESyeizkS3lWnF9QgHlpWYmr4ynuBWPi8r8tye/iyrFzithC7KlWWH9fXC4/Qg
gz9kL0F/TwhgAwL+TywhCHhpTRdvCIyAImCQEJgLBOP/H64v/FJPuL5rBO0xPDP6
fMXXP+1KYuEXF2n4XTDI7HK7z3oTYc6pwBY6q/Jlxmv/3mYv+9Y3oroG3mknwbkP
wkCMrAiPfaRcnevPt/iy1SsBz/DRiFVr/IOzlUVZNKu80vny+iki46ZndSLsld6N
cSUDhc73AUZuleTStbYuJImZnDUt21TZytkyq3fElTJwRKv7HA0cnSDo9pqPwtZo
1N1mZVYoiT1UNuWAq++D00jKdZQNiZYZCszzMYmq4pG7Zqxre7H6i+V3bsWJ8bLq
YcM9f3aFn3+48BvCcDg/sDbB2x2serTWdIF54z3gEBwSAYN4+PyHySvOgZMozrcH
7bHsVfudH8o2bbbsUx7gJ9LAMY9+PH/70SSC0469ZUvjka0Wo8/dphvOC0yuqqkH
gxkT9TRFzzkFL35t2yEtzrHlaU7NtTa/KFtGPUSM0ZCHHkBE7hNZcB+ZErsaclbh
spFIZE3NFukLtt5QBuXXL5uzmujPVxOapmZvnVXOJmcRfswka/0thQnwAJKwH2ji
/i1F4+a1CQ3J89XGD4De/QH1m47wkp/mfmhit05i6JuKBhGUn7+ayqZDN2fDtoEZ
lfSuBuNkzegt6ot/mAgYw2EYCQ8swRNsAEN6eFCmsNu//zRd3LE4gjfEDfcfKLme
yBMo8zKgXeraS7HL4fLmOjYKBsy43OokkT2N2KSgIAvo6/uBxovmj7UA270X1S4j
YVBwPDd7rJ4Wc05p/kjgazcBCIe//Wj8Feq6UfnZJkSLE/OmTfdIVoH0ivZ8mTC+
QaHH++KF6q2poNO8jubXP9hngsx00IRfo+oV33rKJ8pVbcKrgqRsjqE08TsdGWVS
JVKsDn71kvW8wCCq3Ldmp/nvs04R0fxnL9gF8hyK0aYuvfSNeMZoy7lNfAWbUN//
2EnLeuiynnhcaY+gRJZIW2PRYGM4BoPEILzBqngs+vZR7+7t+982SxwsrUKZVSWl
paXVTxqu7kmFk8KUWAA6ULvRnFfH4g8W+rxedV/+U4NLstbrbaeKgy3JPZocrviW
V2kIhyqaEnKb44yEWetCu8nbsyX2uwkPRpnSnMSU83c+Gy4oNlrwfit2f6MLZakn
B+1Y2vMzEbPuJDJR65VVeXHNqOtcH3NsTO3fZyYHbBwYDrro5jH+/ZdeLDMne8NA
ykllagu7dTINZB+ADi1HJZW6uqP3emf7FWW73L14X9xhjEXWbvRM9w4OgnSQ5Kz+
c9mndfo17s54z6ArCrzc2papTIM+FBfWhSgbPyXq185szIC/P1GuW+2HDvavbGbf
+2Q7PnBtRGg41yt+TLVpNRGprWrRZv+zcJQYnpQhH867VgBSXIrJ+C5rZZ3JQrna
/wE=
=irCz
-----END PGP MESSAGE-----


 * Origin: World Power Systems / FidoNews  (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Thu, 8 Oct 92 07:04:56 PDT
To: cypherpunks@toad.com
Subject: Subscribe
Message-ID: <1480@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


SUBSCRIBE

To human overseer:  Please subscribe me to the cypherpunks list...

Thanks,


Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
[.sig revised 1 October 1992    ///    Send mail to eternity node]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no
pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI
lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR
tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j
by51az4=
=LOCL
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Thu, 8 Oct 92 09:15:02 PDT
To: cypherpunks@toad.com
Subject: Apologies for newbie mistake
Message-ID: <1499@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


I apologize for having sent my SUBSCRIBE request to the list-at-large...
I'm setting up a new mail client, and {{excuse}mumble}.


Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
[.sig revised 1 October 1992    ///    Send mail to eternity node]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no
pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI
lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR
tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j
by51az4=
=LOCL
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 8 Oct 92 19:40:31 PDT
To: cypherpunks@toad.com
Subject: Oct. 10 RSVP's
Message-ID: <9210090247.AA02476@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



As of tonight, Thursday 10, the Saturday meeting is in two days.

I'd like to get RSVP's from everyone who plans to attend, so that I
know how many are going to be there.

SEND ONE EVEN IF YOU THINK I KNOW THAT YOU'RE COMING!

I can't keep everyone's attendance plans straight.

Thanks.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 8 Oct 92 23:56:11 PDT
To: cypherpunks@toad.com
Subject: New feature of the remailer
Message-ID: <9210090703.AA26448@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



New!  Just finished.  Fidonet support.  Dumb mailer support.  Incoming
header line pasting.

Here's what's going on.  There are a lot of mailers, the Fidonet
gateway in particular, which don't allow you to put arbitrary header
lines in your outgoing messages.  Previously people using these
systems couldn't use the remailer because they couldn't put the
necessary "Request-Remailing-To:" in the header.

Now they can.  Instead of putting header lines into actual header, I
now support a syntax which allows header lines to be _added_ to the
header on incoming mail.  These extended header lines are in the body
of the message proper, but a filter on incoming mail effectively
adds them to the header.  

This allows anybody who can send me mail with a reasonably unmangled
body to use any feature of the remailer that should ever get written.

Example:

------- cut here -------

To: hughes@soda.berkeley.edu
From: Secret_Squirrel@treehouse.com
Subject: Mrs. Tree's secret recipe for pinole

::
Request-Remailing-To: Crusader_Rabbit@rocky.moosylvania.org

I just paid $2600 for this recipe [etc. etc.]
[...]

------- cut here -------

If "::" is on the first body line all by itself, whatever lines follow
up to the first blank line will be appended to the header when it is
scanned for special instruction lines.

This new feature is completely modular.  It doesn't (seem to) break
any of the other existing features.  I'll post the source with an
explanation tomorrow.

In the meantime, try it out.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Fri, 9 Oct 92 00:14:13 PDT
To: Eric Hughes <hughes@soda.berkeley.edu>
Subject: Re: New feature of the remailer
In-Reply-To: <9210090703.AA26448@soda.berkeley.edu>
Message-ID: <9210090721.AA09749@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain




Now what is needed is a user interface/script for submitting mail.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Fri, 9 Oct 92 01:42:20 PDT
To: cypherpunks@toad.com
Subject: my key
Message-ID: <9210090849.AA09798@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



Here is my casual key, for a more secure key please contact an authorized
dealer near you (Eric Hughes or I).


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx
gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptCZQZXRl
ciBNIFNoaXBsZXkgPHNoaXBsZXlAYmVya2VsZXkuZWR1Pg==
=/Dhz
-----END PGP PUBLIC KEY BLOCK-----







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 9 Oct 92 09:43:05 PDT
To: cypherpunks@toad.com
Subject: The technical explanation of "::" incoming header pasting
Message-ID: <9210091650.AA12173@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



There's a new feature in the remailing software.

Some people can't add arbitrary header fields because of mailer or
gateway restrictions.  This restricts them from using the remailer.  I
have added a facility to allow new header fields to be pasted onto the
end of a header when the mail arrives.  This effectively happens
before processing by the remailer software.  These new fields exist
during transit in the message body, where they remain untouched.  Only
after the message is delivered to my account does this operator
take effect.

Syntax: If the first line of the body is the two characters "::", then
the following lines are appended to the header, up to the next blank
line.

Here's how it works.

First of all, here's my new .maildelivery file:

------- cut here -------
#
# field			pattern	action/	string 
#				result	(quote included spaces)
#
Request-Remailing-To	""	pipe R	"perl remailer/remail.perl" 
Request-Remailing-To	""	file R	remailer/archive
*			""	pipe R	"/usr/local/lib/mh/rcvtty -biff"
*			""	pipe ?	"perl remailer/incoming.header.perl"
------- cut here -------

Comments are indicated by #.  The Request-Remailing-To lines have been
there.  The second of the makes an archive for debugging purposes.  It
will go eventually.  The third field, "*", indicates all fields, it
runs 'rcvtty' on my mail; this replaces the function of biff, since
mail is getting piped to slocal now, disabling biff.

The last line is the important one.  It says "If the mail hasn't been
delivered by now, run the incoming header rewrite script on it.  If
that doesn't work, continue trying to deliver it."

Now here's the trick.  slocal has no way of taking the output of the
rewrite and continuing to process it.  (It should.  It would make this
whole job easy.)  So in order to continue processing, you need to
redeliver the mail.  You could invoke sendmail and mail it back to
yourself, but that would mangle the existing header.  So the thing to
do is to recursively invoke slocal from within the perl script.

Here's the perl script to do all this:

------- cut here -------
  # First read in the whole header.
  # We check for the Second-Pass: line to detect infinite loops.

while (<>) {
	last if /^$/ ;
	exit 1 if /^Second-Pass:/ ;
	$header .= $_ ;
}

  # We have just read the last line in the header.
  # Now we check to see if there is a pasting operator.

if ( ( $_ = <> ) && /^::$/ ) {
	while (<>) {
		last if /^$/ ;
		$header .= $_ ;
	}
} else {
	# There is either an empty body or no pasting operator
	#   Thus exit with a return code of 1 to indicate that
	#   the mail has not been delivered.
		exit 1 ;
}

# There was a header pasting operator.
#   So we open 'slocal' as a pipe, effectively redelivering the mail
#   back to ourselves.

#open( OUTPUT, ">foo" ) ;
open( OUTPUT, "| /usr/local/lib/mh/slocal -user hughes" ) ;
select( OUTPUT ) ;

# print a "From " line to satisfy slocal

@weekdays = ( "Sun","Mon","Tue","Wed","Thu","Fri", "Sat" ) ;
@months = ( "Jan","Feb","Mar","Apr","May",
	"Jun","Jul","Aug","Sep","Oct","Nov","Dec" ) ;
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime ;
printf "From hughes  %s %s ", @weekdays[ $wday ], @months[ $mon ] ;
printf "%2d %02d:%02d:%02d 19%d\n", $mday, $hour, $min, $sec, $year ;

# Now just print out the message

print $header ;
print "Second-Pass:\n" ;
print "\n" ; 
while (<>) {
} continue {
	print ;
}

------- cut here -------

Here's how the perl script works.

The first loop reads lines from the existing header.  When it sees a
blank line (regexp /^$/) it terminates the loop.  If it sees a field
"Second-Pass", it knows it has filtered this message before and exits
with a return code indicating that the mail has not been delivered.
The variable $header is appended with the current header line.
$header contains the whole header when the loop terminates.

Properly speaking, the Second-Pass test is not necessary to detect
infinite loops.  Since the pasting operator gets removed during the
rewrite, the script won't return an exit status of 0 more times than
the pasting operator appears.  But should something get screwed up,
such as a different module adding pasting commands (how? I don't know),
the Second-Pass test should prevent infinite recursion.

The next statement reads another line from the input file.  This line
is the first line of the message body.  If this line is the pasting
operator, then header lines are accumulated in $header as before until
a blank line.  The difference is that these header lines are being
read from the body of the message.  If there is no pasting operator,
the script exits undelivered.

At this point we now have to redeliver the message back to ourselves.
We first open slocal as the output pipe.

The next section is a kludge.  It turns out that slocal strips off the
out-of-band "From " (no colon) line that the mail delivery system
uses.  In other words, the message which slocal pipes into its pipes
is not identical to the message it itself received.  This means that
slocal cannot be directly recursed.  What this section does is to
create a "From " line to make slocal happy.  It calls localtime() and
then formats those numbers into the proper form.

It turns out that slocal will deliver this mail without the "From "
line, even to /usr/spool/mail, but it doesn't do so properly.  On my
system, in added some delimiters which I think I've tracked down to
the 'mtstailor' file, namely mmdelivery1 and mmdelivery2.  Since these
are not null on my system, there's some garbage added which screws up
separation of the spool file into messages.  Adding a "From " line
fixes that.  This misbehavior may not be so surprising, considering
that slocal was "meant" to be invoked only in a .forward file.

Now we print the variable $header which contains the whole header,
including newlines.  Using a single string removes the need for an
array.  We added the Second-Pass line and a blank line for the end of
the header.  The final loop prints out the rest of the message body.

There is another way to proceed to get the same functionality.  One
could write a filter to translate the first occurrence only of
\n\n::\n into \n. We could then pass the message through this filter
before slocal saw it.  And for now, that would do the same thing.

But suppose we want more that one rewrite rule active?  Then you would
only be able to apply each rewrite rule exactly once in fixed order.
You want to be able to rewrite a message and then apply all the
rewrite rules again.  

At least one other rewrite rule is planned: automatic decryption.
Since decrypting a message will completely change the body, and since
some of the header fields may need to be hidden, you have to be able
to decrypt the body and then paste on header lines.  But since you
need to indicate an encrypted body by a header line (well, not really,
but it's more reliable), and since some people can't add these header
lines, you need to paste lines before encryption as well.

Thus the rewrite rules need to be applied asyncronously and hence I'm
using a fairly complex slocal scheme to do a simple filter.
Eventually I hope to write an equivalent to slocal which knows about
message rewrites and simple filters, but that's for later.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Fri, 9 Oct 92 11:13:54 PDT
To: cypherpunks@toad.com
Subject: re: +-=*^
Message-ID: <2747.2AD5CD4D@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> re: problem with key distribution; right, OK, I hadn't 
 U> thought that there might be a security problem with 
 U> casually giving someone your key without them being able 
 U> to authenticate that it came from you.  Good point. 

But as Eric pointed out, and I realized later, the underlying social
structure will allow detection of bum keys (presuming the scammed
person or someone s/he knows notices, etc, and so on, a wholew world
resides here...)

 U> Here's my public key.  If you feel it is not secure 
 U> enough, we can always use the cone of silence:  
 U> 
 U> -----BEGIN PGP PUBLIC KEY BLOCK-----
 U> Version: 2.0
 U> 
 U> 
 U> 23l1t34u
 U> -----END PGP PUBLIC KEY BLOCK-----

Now I feel very unsecure, because the above is all I got. It ain't no
public key...


PS: Too much anonymity? I have to reply in hte mailing list to this
person cuz it's a faked From... (trust me)

 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Fri, 9 Oct 92 11:16:24 PDT
To: Secret_Squirrel@treehouse.com
Subject: Re: +-=*^
In-Reply-To: <9210091712.AA27717@atdt.org>
Message-ID: <9210091823.AA11516@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



>re: Interface for re-mailer; why not hitch it to emacs or something?
> 

that to...

>re: problem with key distribution; right, OK, I hadn't thought that
>there might be a security problem with casually giving someone your
>key without them being able to authenticate that it came from you.  Good
>point.


I look at it this way, by emailing my puplic key anyone can send me a secure 
message (I can't trust where/who it came from but we [the sender and I] can
assume that noone is eavesdroping (it could have been replaced but
not altered or read) 


For secure authenticated, where you *know* if came from me you have to contact
me or someone you trust that has contacted me.

		    -Pete




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Fri, 9 Oct 92 12:20:07 PDT
To: cypherpunks@toad.com
Subject: Re: +-=*^
Message-ID: <9210091926.AA17103@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain




Since there has been complaints about the size of my public key
here is a more secure 512bit version, please discard the prevous key


		-Secret_Squirrel

PS: please redistribute this key asap. to others.


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQBNAirV2r0AAAEB/i78BfdkmEIqKt2EhdlFAJc44rB3ZMzChez5zVcB9jRpUz1o
MY2M2GnucGRUcvMSvZeF/aqCVIHuodDfqyGYYTkABRG0L1NlY3JldF9TcXVpcnJl
bCA8U2VjcmV0X1NxdWlycmVsQFRyZWVob3VzZS5DT00+
=Byn9
-----END PGP PUBLIC KEY BLOCK-----






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Secret_Squirrel@Treehouse.COM
Date: Fri, 9 Oct 92 10:05:09 PDT
To: cypherpunks@toad.com
Subject: +-=*^
Message-ID: <9210091712.AA27717@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


re: Interface for re-mailer; why not hitch it to emacs or something?
 
re: problem with key distribution; right, OK, I hadn't thought that
there might be a security problem with casually giving someone your
key
without them being able to authenticate that it came from you.  Good
point.

Here's my public key.  If you feel it is not secure enough, we can
always use the cone of silence:
 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0


23l1t34u
-----END PGP PUBLIC KEY BLOCK-----




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Secret_Squirrel@Treehouse.COM
Date: Fri, 9 Oct 92 12:51:41 PDT
To: cypherpunks@toad.com
Subject: Anonymity
Message-ID: <9210091959.AA02274@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


Anonymity is good.  Anonymity works.
 
>>
 U> 23l1t34u
 U> -----END PGP PUBLIC KEY BLOCK-----


Now I feel very unsecure, because the above is all I got. It ain't no
public key...\
<<
 
Uh... it's kind of an inside joke.  Uh.  Sorry.
 
Anyway, why would you want to reply only directly to me and not
to the list in general?
 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Secret_Squirrel@Treehouse.COM
Date: Fri, 9 Oct 92 14:53:31 PDT
To: cypherpunks@toad.com
Subject: Ha ha
Message-ID: <9210092201.AA05901@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


Whoah.  That's helarious.  NOT!
 
Secret Squirrel does not cotton to imposters, and that sure
as hell ain't my Public Key.  So don't even bother trying to
write any encrypted messages with it.
 
My key remains: 23l1t34u
 
 
 
 
-- SHRDLU




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Fri, 9 Oct 92 14:18:54 PDT
To: cypherpunks@toad.com
Subject: *Economist* on encryption
Message-ID: <1632@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


The following is intended for limited-distribution, educational purposes
only....



Citation:    The Economist, Sept 21, 1991 v320 n7725 p104(2)
             COPYRIGHT Economist Newspaper Ltd. (UK) 1991

----------------------------------------------------------------------

Title:       A cure for the common code: computer cryptography.

----------------------------------------------------------------------

Subjects:    Public key cryptosystems_Standards
             Digital signatures_Standards
             Data encryption_Research
             United States. National Institute of Standards and
               Technology_Laws, regulations, etc.

Reference #: A11286848

======================================================================

Summary: Advances in the mathematics of prime factorization algorithms
         have led to a technology that, once standardized, will
         dramatically improve public-key cryptography. The RSA
         algorithm is popular in the computer industry, but the
         government favors an alternative.

======================================================================

ANYONE can sign a postcard, but how do you sign a piece of electronic
mail? Without a "signature" to demonstrate that, say, an electronic
transfer of funds really comes from someone authorised to make the
transfer, progress towards all-electronic commerce is stymied. Ways of
producing such signatures are available, thanks to the technology of
public-key cryptography. They will not work to everyone's best
advantage, though, until everyone uses the same public-key system. It
is an obvious opportunity for standards-makers - but in America they
have turned up their noses at all the variations on the theme
currently in use. The alternative standard for digital signatures now
offered by America's National Institute of Standards and Technology 
(NIST) has brought a long-simmering controversy back to the boil.

Public-key cryptography could become one of the most common
technologies of the information age, underpinning all sorts of routine
transactions. Not only does it promise to provide the digital
equivalent of a signature, it could also give users an electronic
envelope to keep private messages from prying eyes. The idea is to
create codes that have two related keys. In conventional cryptography
the sender and receiver share a single secret key; the sender uses it
to encode the message, the receiver to decode it. In public-key
techniques, each person has a pair of keys: a disclosed public key and
a secret private key. Messages encoded with the private key can only
be decoded with the corresponding public key, and vice versa. The
public keys are published like telephone numbers. The private keys are
secret.

With this technology, digital signatures are simple. Encode your
message, or just the name you sign it with, using your private key. If
the recipient can decode the message with your public key, he can be
confident it came from you. Sending a confidential message - putting
electronic mail in a tamper-proof envelope - is equally
straightforward. To send a secret to Alice encode it with her public
key. Only Alice (or someone else who knows her private key) will be
able to decode the message.

The heart of any system of public-key cryptography is a mathematical
function which takes in a message and a key, and puts out a code. This
function must be fairly quick and easy to use, so that putting things
into code does not take forever. It must be very hard to undo, so that
getting things out of code does take forever, unless the decoder has
the decoding key. Obviously, there must be no easy way to deduce the
private key from the public key.

Finding functions that meet these criteria is "a combination of
mathematics and muddle", according to Roger Needham of the Cambridge
Computer Laboratory. The greatest successes to arise from the muddle
so far are those using functions called prime factorisation
algorithms. They are based on the mathematical insight that, while it
is easy to multiply two numbers together, it is very hard to work
backwards to find the particular two numbers which were multiplied
together to produce some given number. If Alice chooses two large
prime numbers as her private key and publishes their 150-digit product
as her public key, it would probably take a code-breaker thousands of
years to work backwards to calculate her private keys. A variety of
schemes have been worked out which use this insight as the basis for a
workable public-key code.

Most popular of these is the so-called RSA algorithm, named after the
three MIT professors who created it - Ronald Rivest, Adi Shamir and
Len Adleman. It has been patented and is sold by a Silicon Valley
company, called RSA, that employs 15 people, most of them ex-MIT
graduate students. Faculty firms are to computer start-ups what family
firms were to the industrial revolution. RSA has attracted both
academic praise and a range of heavyweight commercial customers:
Microsoft, Sun Microsystems, Digital Equipment and Lotus Development.
But, despite repeated applications, it has never been endorsed by
those in government.

Rumours abound that the code-breakers in the National Security Agency
have discouraged standard-setters from recommending RSA because they
do not want to promote the use of codes they cannot break. RSA, for
obvious reasons, does not discourage the rumours. Whatever the reason,
the standard-setters at the NIST have side-stepped the debate over RSA
with their new algorithm, DSA. As set out in the standard, DSA
verifies the identity of the sender, but does not encrypt the message.
It appends to the message a number calculated from the message and the
sender's private key. The recipient can then use this number, the
message and the sender's public key to verify that the message is what
it seems.

The NIST says that this technique is well suited to "smart cards" and
other applications where there is not a lot of computing power
available for working out codes. Because it hopes that DSA Will be
used for verifying the identity of everyone from welfare recipients to
military contractors, its flexibility is a boon. Meanwhile, however,
more and more companies are choosing a public-key cryptography system
for communicating confidentially - often RSA, sometimes something
different. Someday, probably soon, governments will want to choose,
too. Watch out for fireworks when they do.

------------------end forwarded article--------------------------


Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
[.sig revised 1 October 1992    ///    Send mail to eternity node]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no
pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI
lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR
tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j
by51az4=
=LOCL
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Angry_Poodle@BBQ.COM
Date: Fri, 9 Oct 92 18:47:57 PDT
To: cypherpunks@toad.com
Subject: PGP Key
Message-ID: <9210100155.AA12001@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


If you see any msgs from 'me' saying "here's my PGP PK key,"
then it's an imposter!  I don't have a PGP key, much less PGP!
 
-- Angriest Dog in the World.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF)
Date: Sat, 10 Oct 92 03:07:47 PDT
To: cypherpunks@toad.com
Subject: a key
Message-ID: <9210100755.AA05427@kg6kf.ampr.org>
MIME-Version: 1.0
Content-Type: text/plain


A key...

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQA9AirWaLMAAAEBgMlJILifxrXH8fkJwJbeSHXAY1Q9/AzPybGVy0Dx/q70Fr3d
KhM6XoSEgaw2Ezzn2QAFEbQWTWFyYyBkZSBHcm9vdCAoY2FzdWFsKbQjTWFyYyBk
ZSBHcm9vdCA8bWFyY0BrZzZrZi5hbXByLm9yZz4=
=LL6T
-----END PGP PUBLIC KEY BLOCK-----

This is a casual key for me.  Perhaps a causal key for me too.

-Marc de Groot <marc@kg6kf.ampr.org>





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sat, 10 Oct 92 01:59:50 PDT
To: shipley@tfs.COM
Subject: Re: +-=*^
Message-ID: <199210100906.AA26559@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


I've seen a number of postings so far about "secure *and* authenticated"
requiring advance in-person distribution of key material.  This would seem
to eliminate the main advantage of public key systems, i.e. open
distribution of public keys.  So as long as we're handling key material in
person, how about one-time systems, eh?  Absolutely secure, provably so,
obsolescence-proof, simple & straightforward.  Not particularly exciting
from a theoretical point of view, but one-time systems are practical and on
the bottom line, they work.  What do y'all think...?

-gg@well.sf.ca.us




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Sat, 10 Oct 92 02:43:25 PDT
To: cypherpunks@toad.com
Subject: Better directions to the meeting on Saturday at noon
Message-ID: <9210100950.AA28200@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


Someone asked for better directions, and the original ones were
pretty skimpy anyway.  Here's a better try.

	Cygnus Support
	1937 Landings Drive
	Mt. View, CA  94043

There's no phone service there yet.

Take US 101 toward Mt. View.  From San Francisco, it's about a
40-minute drive.  Get off at the Rengstorff Ave/Amphitheatre Parkway
exit.  If you were heading south on 101, you curve around to the
right, cross over the freeway, and get to a stoplight.  If you were
heading north on 101, you just come right off the exit to the
stoplight.  The light is the intersection of Amphitheatre and
Charleston Rd.  Take a right on Charleston; there's a right-turn-only
lane.

Follow Charleston for a short distance.  You'll pass the
Metaphor/Kaleida buildings on the right.  At a clump of palm trees and
a "Landmark Deli" sign, you can take a right into Landings Drive; this
gets you into the complex from the north.  Or you can go slightly
further along Charleston and take the next right, into a driveway with
a big "Landmark" sign in the middle.  No matter which way you got into
the complex, follow around it until you are on the side that faces the
freeway.  There's a clock tower that rises out of one of the
buildings, to the right (south) of the deli.  Enter through the doors
immediately under the clock tower.  They'll be open between noon and
1PM at least.  (See below if you're late.)

Once inside, take the stairs up, immediately to your right.  At the top
of the stairs, turn right past the treetops, and we'll be in 1937 on 
your left.

If you are late and the door under the clock tower is locked, you can
go to the deli (which will be around a building and left, as you face
the door), cut between the buildings to the right of the deli, and
into the back lawns between the complex and the farm behind it.  Walk
around the buildings until you see a satellite dish in the lawn.  Go
up the stairs next to the dish, which are the back stairs into the
Cygnus office space.  We'll prop the door (or you can bang on it if we
forget).

Or, you can find the guard who's wandering around the complex, who
knows there's a meeting happening and will let you in.  They can be
beeped at 965 5250, though you'll have trouble finding a phone.

Don't forget to eat first, or bring food at noon!  I recommend hitting
the burrito place on Rengstorff (La Costen~a) at about 11:45.  To get
there, when you get off 101, take Rengstorff (toward the hills) rather
than Amphitheatre (toward the bay).  Follow it about ten blocks until
the major intersection at Middlefield Road.  La Costen~a is the store
on your left at the corner.  You can turn left into the narrow lane
behind the store, which leads to a parking lot, and enter by the front
door, which faces the intersection.  To get to the meeting from there,
just retrace your route on Rengstorff, go straight over the freeway,
and turn right at the stoplight onto Charleston; see above.

See you there!

	John Gilmore




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sat, 10 Oct 92 07:29:03 PDT
To: cypherpunks@toad.com
Subject: +-=*^
In-Reply-To: <199210100906.AA26559@well.sf.ca.us>
Message-ID: <9210101436.AA00257@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



George recommends one-time pads.

The key distribution problem for one-time pads is *much* worse than
for public key systems, or even conventional secret key ciphers for
that matter.  You still have to exchange keys without transmission
(i.e. face to face meetings again, or mail, etc.).  Anything that is
secure for exchanging a one-time pad is also secure for exchanging
public keys.  Then you have to do this again when your pad runs out.
The bandwidth required for one-time keys is much higher than for
conventional keys to boot.

But the biggest advantage of public key systems is that I can sign
someone else's key, and if you know my key, then you know his.

To put it more humorously, you will have exchanged cryptographic
fluids with everyone I have as well.  This is a good thing.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sat, 10 Oct 92 12:20:43 PDT
To: cypherpunks@toad.com
Subject: Directions!
Message-ID: <2887.2AD7240A@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Umm, directions never came. I think it's last minute, huh?! Can
anyone tell me where Cygnus' new site is?


 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sat, 10 Oct 92 13:15:11 PDT
To: cypherpunks@toad.com
Subject: re: Better directions to the meeting on Saturday at noon
Message-ID: <2889.2AD73B41@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Things are not good here. I have to stay and deal with my best friend
Deke who seems to be going nuts. (It's not a new story, but it heated
up last night.) Now, at 1pm, I've gotta stay here another hour or so,
and be back by 630, so I guess I'm gonna have to miss another. I'll
see you all elsewhen (to borrow a Hugh-ism).

 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sat, 10 Oct 92 13:15:12 PDT
To: cypherpunks@toad.com
Subject: re: Re: +-=*^
Message-ID: <2890.2AD73B43@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



(to: gg@well.sf.ca.us)

Thank you for clarifying my particular problem: what I was worried
about was *authentication* not security. I had the two tangled up.
Duh. 

With an informal email/introducer setup for the FidoNet, we'll have a
fairly secure system with a reasonable level of authentification,
practically speaking, with authentification to some high level doable
on an individual basis. (Using PGP.)

This probably as "good as it gets" in our (email) environment.


 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Sat, 10 Oct 92 13:33:53 PDT
To: cypherpunks@toad.com
Subject: random
Message-ID: <9210102041.AA04891@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



So when are we going to start alt.crypt, where we just post a lot of
uuencode'ed random data?

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 10 Oct 92 11:04:58 PDT
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Mr. Squirrel?
Message-ID: <921010180751_74076.1041_DHJ61-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


Hi, I've just joined this list.

Interesting confusion about Mr. Squirrel.  That's one of the problems
with anonymity.  How do you know you're talking to the right person?

What you should do is to use a public key.  The pseudonym is not
really the name "Secret Squirrel"; anybody can use that.  The pseudonym
is the public key.  Any message signed by that particular key is from
that particular squirrel.  Any message you encrypt in Squirrel's public
key is readable only by him.  If Squirrel changes his key, he should
sign the message so you know it's really _that_ squirrel who's changing
his key (and not some other squirrel telling people to use a new key).

A pseudonym is a public key.

Hal

P.S. Here's my key, signed by PRZ:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.01

mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
=fF6Z
-----END PGP PUBLIC KEY BLOCK-----






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: d9mj@crux2.cit.cornell.edu
Date: Sat, 10 Oct 92 17:55:26 PDT
To: cypherpunks@toad.com
Subject: [gg@well.sf.ca.us: Re: +-=*^]
Message-ID: <9210110102.AA21921@crux1.cit.cornell.edu>
MIME-Version: 1.0
Content-Type: text/plain



Look at what my mailer did to your header. Is this a result of your
perl script or my screwed router?

Date: Sat, 10 Oct 1992 05:06:40 -0400
Illegal-Object: Syntax error in From: address found on router.mail.cornell.edu:
	From:	George A.Gleason <gg@well.sf.ca.us>
		^	^-illegal period in phrase
		 \-phrases containing '.' must be quoted
X-Ph: V3.12@router.mail.cornell.edu
>From: <gg@well.sf.ca.us>
To: Secret_Squirrel@treehouse.com, shipley@tfs.COM
Subject: Re: +-=*^
Cc: cypherpunks@toad.com

[message deleted]




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sun, 11 Oct 92 00:50:52 PDT
To: hughes@soda.berkeley.edu
Subject: Re:  +-=*^
Message-ID: <199210110757.AA22987@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



Eric, good point about public keys and trust by association.  

More on OTPs.
You say the key distribution problem for OTPs is "much worse" than for PKS
and even other conventional ciphers.  "Much worse" in what ways?  The need
for F2F meetings with all possible correspondents is something which exists
with conventional ciphers.  The cost of key storage is trivial: a fraction
of the cost of the yearly (or less frequent) travel to meet each
correspondent in person.  Consider replaceable hard drive cartridges (30 meg
for about a buck a meg), digital cassette formats including applications
involving videocassettes, and so on.  Yes, as you say, you have to exchange
keys each time you run out of key; but you can keep ten years' with of key
(error: "worth" not "with") on hand if you like, taking up less physical
space than a box of cookies.  

"Bandwidth required is much higher..."  In what way?  Certainly not in terms
of transmission; a stream cipher is a stream cipher.  Perhaps in that each
plaintext character requires one key character?  This is just another
formulation of the "storage" issue: and again, if you have a stack of 30MB
cartridges, who cares?  Not like we're talking about punched paper tape.

I do agree that PKS offer convenience and features not available with
conventional ciphers.  However, RSA is just one mathematical breakthrough
away from being obsolete, and we have no way of knowing when that
breakthrough occurs.  It may also be that massively parallel processors can
be built through VLSI technology, allowing the cost of brute force solutions
to come down to a reasonable level.  

All of this is not by way of getting down on PKS.  I would suggest that we
need a number of different systems, and need to keep them all in fairly
constant use.  I think we're already all in agreement that one of those
systems should be RSA-based.  Now I'm just suggesting that a One-Time system
should be another one among the many.

BTW, sorry I couldn't make today's meeting; various local tasks demanding
attention; plus physical travel distance.   Be back next time...

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sun, 11 Oct 92 11:52:09 PDT
To: cypherpunks@toad.com
Subject: [gg@well.sf.ca.us: Re: +-=*^]
In-Reply-To: <9210110102.AA21921@crux1.cit.cornell.edu>
Message-ID: <9210111718.AA24207@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



There is a bit of confusion about the various lists and addresses.

My main address is hughes@soda.berkeley.edu.  The remailer runs from
this account.  All the perl scripts are there.

The account I use to maintain the mailing list is on toad.com, as well
as the mailing list itself.  Its software is nothing but sendmail; no
perl scripts.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sun, 11 Oct 92 11:52:00 PDT
To: cypherpunks@toad.com
Subject: one time pads
In-Reply-To: <199210110757.AA22987@well.sf.ca.us>
Message-ID: <9210111753.AA24487@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


George writes:

   The cost of key storage is trivial: a fraction
   of the cost of the yearly (or less frequent) travel to meet each
   correspondent in person.

Let me emphasize _each_ in that sentence.  One time pads are very
expensive on a per-link basis than public key systems for this reason
only.  Per-link is one person-to-person link.

   Consider replaceable hard drive cartridges (30 meg
   for about a buck a meg), digital cassette formats including applications
   involving videocassettes, and so on.  

Suppose one cartridge per link.  That's $30 per link.  Per link,
that's a _lot_ of money.

   "Bandwidth required is much higher..."  In what way?  

Whatever channel you use to transmit keys on, be it 30 Mb cartridges
or what, will be more efficiently used by an exchange which requires
less storage.  In the case of cartridges, the UPS cost to ship one is
still only about 1/5 of the cost of a cartridge.  A 3 1/2 inch floppy
can be shipped for one or two ounces of postage.

   However, RSA is just one mathematical breakthrough
   away from being obsolete, and we have no way of knowing when that
   breakthrough occurs.

It is also one breakthrough away from being known to be fully secure.
Not only do we not know when that will happen, we don't know which
will happen.

   It may also be that massively parallel processors can
   be built through VLSI technology, allowing the cost of brute force solutions
   to come down to a reasonable level.  

Look at the figures for best know factoring algorithms.  Now estimate
the total amount of silicon output per annum in the US and estimate
it's computational ability.  I think you'll find that it would still
take on the order of years to factor a single 1024 bit modulus.

The difficulty of hard problems and the scale of the solar system are
two things which are both extremely difficult to get any intuition
about.

   I would suggest that we need a number of different systems, and
   need to keep them all in fairly constant use.  [...]  Now I'm just
   suggesting that a One-Time system should be another one among the
   many.

Here's the bottom line: More security, more cost.  Perfect security is
not worth the cost in time, effort, or dollars when the marginal cost
of perfection is less than the marginal benefit.

Even SWIFT, the international monetary wire transfer system, does not
use one time pads for link encryption.  Now here is a network which
breaking into would be worth billions (that's thousands of millions,
let me remind you).  The chief executives of SWIFT exchanges keys by
post.  

One time pads are useful for all sorts of things, but they are very
expensive to use.  They are useful in protocols for blinding and key
exchanges.  They do not seem to be useful for end-to-end link
encryption, however.

Eric






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 12 Oct 92 08:20:43 PDT
To: cypherpunks@toad.com
Subject: Next meeting: Nov. 21
Message-ID: <9210121527.AA23015@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



The next physical cypherpunks meeting was decided on Saturday at
that meeting.  It will be Saturday, November 21, starting at noon at
the Cygnus Support offices in Mountain View.  I am announcing the date
now so that you can put it on your calendar.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Mon, 12 Oct 92 02:29:15 PDT
To: cypherpunks@toad.com
Subject: More on packet radio encryption
Message-ID: <1778@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain



This article was forwarded to you by whitaker@demon.co.uk (Russell E. Whitaker):

--------------------------------- cut here -----------------------------

Path: eternity.demon.co.uk!demon!pipex!unipalm!uknet!doc.ic.ac.uk!agate!spool.mu.edu!sgiblab!public!grady
From: grady@public.BTR.COM ( )
Newsgroups: alt.privacy
Subject: packet radio encryption
Message-ID: <8113@public.BTR.COM>
Date: 11 Oct 92 19:41:12 GMT
Organization: BTR Public Access UNIX, MtnView CA. For info contact: info@BTR.COM
Lines: 52

Bill Stewart (wcs@anchor.ho.att.com) writes, in part:
         
   [...Unlike the AX.25 link protocol specified by FCC rules, the higher
   level protocols are not required to be plain-text...]

Do you have a reference for this?  And does this apply to the contents,
the protocols, or both?  (E.g. can you use a crypto-based presentation
layer protocol and plain-text payload, or vice versa?)

----

The definitive reference is Part 97 of the FCC rules
(available from the US Government Printing Office,
Washington, D.C.  20402.  Phone orders: 202 783 3238.
Ask for "Code of Federal Regulations" 47 CFR 80 to End.)

To summarize the rules, except for certain remote control
operation as space or repeater machines, nothing can be 
transmitted with the intent that the meaning be obscured.

Conversely, text compression, for example, is legal because,
although the plaintext is certainly obscured, it wasn't the _intent_
of the LZ or Huffman or whatever coding to conceal the
meaning.

Likewise with UUencoding and a host of other compression/
error detection and correction schemes that incidentally
involutes the plaintext to some more efficient transmitted form.

Spread spectrum is treated somewhat more restrictively
since for that mode you may be required to produced the
logs and the content of the messages.  But not so for narrow-
band FM packet.

To sum up, using cryptography in general is prohibited.
(However, digital signatures are OK, even though based
on MD5 or SHA as long as the intent is not to _obscure the
meaning_ of part of the transmitted message.)

Clearly, though, the burden of proof is upon the FCC to show
that a particular message _was_ encrypted, since there
is _no_ theoretical, a priori way that an encrypted data
stream can be distinguished from one merely well compressed
or, just for that matter, random.

Of course you should verify this with an attorney if you are
troubled with fears of prosecution.

Grady Ward    KD6ETH/AA

-- 
Grady Ward  grady@btr.com  Moby Lexicons


--------------------------------- cut here -----------------------------





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ravi@xanadu.com (Ravi Pandya)
Date: Mon, 12 Oct 92 13:46:47 PDT
To: cypherpunks@toad.com
Subject: The subject of Saturday's game
Message-ID: <9210121942.AA03720@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


I just joined the list; I've read such archives as are locally
available, but I apologize if this subject has already come up.

Talking to a couple of people who had been to Saturday's meeting, I
was deeply disturbed by the choice of subject for the simulated
privacy game - trying to purchase illegal drugs. This is a subject on
which rational public discussion is essentially non-existent in this
country. Let me first state that I do favor the legalization of drugs,
and I am a committed libertarian (as I suspect are many of the people
in this group).

However, I think it is unwise to tie cryptography in with this issue.
Communications privacy is *too important* to take the risk that it
will get caught up in the current hysteria of the New Prohibition.
There have already been enough government attacks on cryptography that
we do not want to give them any more ammunition.

I think that if we are committed to getting cryptographic technology
in wide use, and spreading true privacy and information security
throughout the world, then we need to take careful account of the
political and social factors, as well as the technical. In order to be
successful, this needs to be not just a development project, but also
a marketing campaign.  When an MIS manager at some large corporation
is deciding whether to upgrade her network to privacy-enhanced mail,
we want her to associate it with security and liberty, not the street
corner punks who are trying to sell her kids crack.

In this vein, let me suggest some subjects for future simulations:

	- organizing the Boston Tea Party in the face of British spies
	and informers

	- purchasing condoms or Lady Chatterley's Lover back when they
	were banned (these bans seem so absurd now, that trying to get
	around them seems sensible and ordinary, and may start people
	thinking about the absurdity of current interdictions)

	- Yeltsin/Gorbachev vs the coup leaders

Furthermore, given the erosiion of constitutional protections in the
Drug War, I think the participants in Saturday's game were taking a
non-trivial risk to their persons and property. If the risk were
necessary to help spread cryptographic privacy, I think none would
begrudge it; however, I think it was not only unnecessary, but
counterproductive. 'Nuff said.

To life and liberty,
	--ravi





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Mon, 12 Oct 92 15:09:10 PDT
To: uunet!xanadu.com!ravi@uunet.UU.NET
Subject: The subject of Saturday's game
In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com>
Message-ID: <9210122148.AA05516@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


Excellent message.  I agree with your points about drugs.  I also like
the organization topics you suggest for the game.  

	 In this vein, let me suggest some subjects for future simulations:

		 - organizing the Boston Tea Party in the face of British spies
		 and informers

		 - purchasing condoms or Lady Chatterley's Lover back when they
		 were banned (these bans seem so absurd now, that trying to get
		 around them seems sensible and ordinary, and may start people
		 thinking about the absurdity of current interdictions)

		 - Yeltsin/Gorbachev vs the coup leaders

On the victory conditions.  Right now, the game is declared over as
soon as any party accomplishes their objective.  This creates the
incentive to prevent other people from accomplishing their objective,
even if it would help me accomplish mine.  

The use of topics like the above gives clearer victory conditions:
One side or the other wins, even though that side only loosely
includes any particular participant in the game (an informer wins if
either his nominal side wins without his duplicity being revealed, or
if the opposition wins).

A plausible generic form of victory condition is for one 'side' to
succesfully transact some secure exchange, or for the other 'side' to
successfully break such a secure transaction.  I don't know how to
allow decoys with this model of victory.  Hmmm...

	 To life and liberty,

Da.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 12 Oct 92 15:40:05 PDT
To: cypherpunks@toad.com
Subject: Game items
In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com>
Message-ID: <9210122247.AA01207@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: drugs and simulation games.

At the meeting last Saturday, we played the second incarnation of the
remailing simulation game.  In a nutshell, the game is intended to
teach people about how to protect their privacy by using encryption to
prevent against monitoring and by using remailing to protect their
identities.  Since the game is also in part an economic simulation, I
tried to pick game objects which someone had some interest in keeping
quiet.  I picked drugs, of unspecified name, as a prominent game item.
This, by wide acclamation, is a mistake.  Since the primary reason to
pick this was a paucity of imagination, I now ask for help from the
list.

We want to develop a list of game items, physical objects, which will
be the goods of transaction.  I would like to pick objects that have
been illegal in the past, but which are not anymore.  They should not
be primarily information, such as copies of _Ulysses_.  They should
not now be restricted.  Nor should they be weapons, such as crossbows
or samurai swords.  They should, however, be objects that are known to
have generated some emotional reactions in the past.

There are two suggestions that meet these criteria: contraceptives and
printing presses (or xerox machines).  I would like to find more.
Please make your suggestions.

Another possibility is to use items which have been the subject of
state-enforced monopolies in the past, such as pepper or nutmeg.

Be creative.  We'd like to get a good list of twenty or so items.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: efrem@spitha.informix.com (Efrem Lipkin)
Date: Mon, 12 Oct 92 20:56:33 PDT
To: cypherpunks@toad.com
Subject: Re: drugs and simulation games.
Message-ID: <9210130254.AA04987@spitha.informix.com>
MIME-Version: 1.0
Content-Type: text/plain


Unfortunately the first two things which come to mind are:

coffee (a drug - actually an excuse for gathering)
papers on public key cryptography (primary information)

radios - illegel in Russia and I believe elsewhere during WWII
East German typewriters - I had one

Also a slight deviation: many medicines (and soon herbal contraptions) 
which are doctor monoply items here, but over the counter in most other
countries.

Religious artifacts of any number of banned religions.

Divorce (opps, not a physical object).

Really on thinking about it, I believe that the trade of ideas is always
far more repressed than the trade in any kind of stuff.

--Efrem


Re:
> We want to develop a list of game items, physical objects, which will
> be the goods of transaction.  I would like to pick objects that have
> been illegal in the past, but which are not anymore.  They should not
> be primarily information, such as copies of _Ulysses_.  They should
> not now be restricted.  Nor should they be weapons




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Mon, 12 Oct 92 21:57:42 PDT
To: uunet!spitha.informix.com!efrem@uunet.UU.NET
Subject: drugs and simulation games. Really on thinking about it, I believe that the trade of ideas is always far more repressed than the trade in any kind of stuff.
In-Reply-To: <9210130254.AA04987@spitha.informix.com>
Message-ID: <9210130425.AA01334@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


	 --Efrem

	 > We want to develop a list of game items, physical objects, which will
	 > be the goods of transaction.  I would like to pick objects that have
	 > been illegal in the past, but which are not anymore.  They should not
	 > be primarily information, such as copies of _Ulysses_.  They should
	 > not now be restricted.  Nor should they be weapons

We definitely should have physical goods because the interface between
an information world (in which privacy and anonymity can be completely
protected) is where much of the complexity lies in managing things
like cryptographic money.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Mon, 12 Oct 92 21:56:16 PDT
To: ravi@xanadu.com (Ravi Pandya)
Subject: Re: The subject of Saturday's game
In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com>
Message-ID: <9210130503.AA15950@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



That was a really good point.  Keep separate issues separate so as not to
alienate people.

e





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Tue, 13 Oct 92 01:14:58 PDT
To: hughes@soda.berkeley.edu
Subject: Re:  one time pads
Message-ID: <199210130821.AA03658@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Good hard critique, Eric!  Now if I might try to salvage my position...

"One time pads are very (much more) expensive on a per-link basis than
public key systems..."  

Yes, of course.  However I don't envision OTPs as a standard for bulk
encryption on large networks.  Rather, for person-to-person communication in
small networks.  Examples: a group of civil rights attorneys suing the
Federal govt., an international environmental organisation's main offices in
the capital cities of a small number of countries, etc.  Cases where the
adversary is one or more powerful governments, and the number of links
required is relatively small.  Given the nature of the relationships between
these kinds of networks and their adversaries, the expense would seem to be
justified; in any case, the **incremental** cost of for instance a set of
30MB cartridges as compared to a few floppy discs, is an minor fraction of
the cost of the airline tickets and other expenses for trusted couriers.
(oops: "a minor fraction...")

Your discussion of bandwidth can be met with a similar counter-arguement.
First of all, I would reject the use of UPS or (God help us) the *Post
Office* as a courier, particularly where one or more governments may be the
adversaries against whom protection is needed.  
So your reference to those carriers is not relevant to the main point of my
case.  I'm assuming that key materials are transported by trusted courier
and are guarded by same until they reach their intended recipient.  Okay,
that *really* drives up the cost, doesn't it...?  Not if the key materials
"hitch hike" on an existing travel plan: attorney A flies out to city B to
visit attorney B... and happens to carry key material onboard in his/her
shoulder bag.  No added cost except for the storage devices, and that is not
significant.  

Re mathematical breakthroughs in factoring etc, you say, "we don't know when
that will happen, and we don't know which will happen."  Exactly my point.
*We* don't know.  But the NSA and so on, most certainly do know, and they
won't be telling.  If the breakthrough comes, then the period between that
point and the point when it is publicised, will be one of false security.
Was it Kahn who said nothing is more dangerous than a bad cipher?  My point
here comes down to nothing more or less than the principle of caution in the
face of an unknown.  

(Discussion of relative cost of brute force solutions, and the question of
hard problems and scale.)  I agree that my intuition about these things may
be highly flawed. However this doesn't invalidate my point about the
possibility of basic breakthroughs happening behind closed doors.  Now in a
way I'll admit that my arguement here sort of comes down to a black box.
However, again I would assert that there are cases where the almost
irrational caution is worthwhile.  

You say in concluding, "Perfect security is not worth the cost in time,
effort, or dollars when the marginal cost of perfection is less (do you mean
more?) than perfection."  You cite examples of international banking
systems.

I would cite examples of political movements which have been sabotaged and
destroyed by government covert action.  One need not look far to run into
COINTELPRO and the more recent French govt action of blowing up a Greenpeace
vessel.  Where your adversaries are the intelligence agencies of world
powers, and where lives are at stake, I would say the cost of perfect
security is justified.  Now of course, the French terrorist bombing, the
destruction of Black nationalist and student organising groups in the US,
and other examples, may not (probably would not) have been prevented
altogether by adoption of perfect communications security.  Che Guevara
after all used OTPs, and it was radio direction finding and traffic analysis
(rather than cryptanalysis) which ultimately led to his murder by US-backed
mercenaries.  

If we are promoting a tendency which is inherently political, it implicitly
recognises governments as its adversaries.  Our choices of cryptographic
systems should reflect a wide range of applications and not exclude some
a-priori on grounds of cost or convenience.  

-George (gg@well.sf.ca.us)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Tue, 13 Oct 92 01:49:34 PDT
To: hughes@soda.berkeley.edu
Subject: Re:  Game items
Message-ID: <199210130856.AA05294@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


The examples I always refer to are Federal civil rights suits naming the
Federal govt as defendant, and international ecological organisations
conducting whatever business they may be engaged on.  These may or may not
fulfill the game objectives, and they do tend to suffer from being a bit
mundane perhaps to the point of being unexciting.  However they are
historically relevant and probably will be so in the future.

Another possible topic would be womens' access to abortion, though given the
coming change in our govt this may be irrelevant.  

How about GIFs depicting sex between consenting adults?  Corporate
proprietary information on new technology, in an age of increasing
international competition (in this case the physical prototypes as well as
information about same).  International intrigues are always interesting:
small countries seek to combine economic power against large countries, that
kind of thing.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hugh@domingo.teracons.com (Hugh Daniel)
Date: Tue, 13 Oct 92 05:02:06 PDT
To: CYPHERPUNKS@TOAD.COM
Subject: Mr. Squirrel?  Just who is whom here?
In-Reply-To: <921010180751_74076.1041_DHJ61-1@CompuServe.COM>
Message-ID: <9210131201.AA12086@domingo.teracons.com>
MIME-Version: 1.0
Content-Type: text/plain


  Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone
can use any public key they want also.  So, in a many-to-one scope (as
in a maillist) where the sender can not use the one-on-one signed
signiture method how do we have proff of who the sender really is?
  Maybe public forums are just not places where it is easy to verify
the identity of a speaker?

  A second thing that Hal's comments bring up is that we were reading
the From: headders and ignoreing the keys.  In good crypto-mail
readers the key ought to be checked against our own data base of
others keys and the result added to the hedders as say:
	KeyCheck: FooBar Bazoid holds this key in XXX database
or some such rot.  I wonder what is more important, who I claim to be
in a random message or what key I include...
  New keys ought for an ID (or new ID's for the same key) should be
added to the data base as well.
  But all this needs to be done automaticly by the mailers and
interfaces, else the system will be mis-used and folks will tire of
the extra work that gets them little advantage.

		||ugh Daniel




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 13 Oct 92 08:51:51 PDT
To: cypherpunks@toad.com
Subject: one time pads
In-Reply-To: <199210130821.AA03658@well.sf.ca.us>
Message-ID: <9210131558.AA25287@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Previously I said about one-time pads: "High security, high cost."
(Well, not exactly that...)  I invoked it then in order to argue that
I personally didn't need to use one-time pads.  Implicit also in that
statement is the claim that when the worth of security is high, the
cost may be relatively cheap.  George and I agree on this point.

When you are fighting a military battle, when you have a government
pissed off at you in a serious way, you need as good as you can get.
Since you can get perfect end-to-end link encryption, you use it.

All cryptography is economics.  Repeat after me.  All cryptography is
economics.

I don't need one-time pads.  Sendero Luminoso does.  It's as easy as
that.  It's merely a matter of scale.  Large scale, high security.
Small scale, pretty good security.

Re: Mathematical breakthroughs.  George missed my main point here.  We
don't know whether factoring is "fundamentally hard." (Project your
own definition here.)  We should not assume that when the breakthrough
comes, that is will be found "easy."  It may be that factoring is
hard, and that RSA is secure for that reason.  (The astute reader will
see that these two are not exactly the same question.)  My current
thinking is that factoring is hard because of various randomness
properties of primes, that in fact multiplying one large prime by
another is like encrypting one prime with the other as a one-time pad!
But I'm no number theorist.

I do, however, agree with "caution in the face of an unknown."  And
for high stakes, George's "irrational caution" is not irrational at
all.

Re: Relative security.  It seems I had an editing error.  What I meant
to say (paraphrased) was the following.  Perfect security is not worth
the cost when the marginal cost of perfect security is more than the
marginal benefits of such security.  This encompasses both the high
end and the low end.  I don't need one-time pads.  Abu Nidal does.

Repeat after me.  Cryptography is all economics.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 13 Oct 92 09:03:14 PDT
To: CYPHERPUNKS@TOAD.COM
Subject: Mr. Squirrel?  Just who is who here?
In-Reply-To: <9210131201.AA12086@domingo.teracons.com>
Message-ID: <9210131610.AA25466@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Hugh asks how, in a broadcast network, we may verify identity.  The
answer is "statistically."  Not everyone needs to verify each message;
only those who communicate with the sender personally (and who thus
know the private keys) need to.

Hugh mentions the "one-on-one signed signature method" and that it is
not applicable to broadcast.  Well, signing the whole message is not,
but signing a message digest is.  This is the whole reason for message
digests, that a message may go out in cleartext, but the validating
information for that message be encrypted.  Thus everyone can read the
message, even without knowledge of the public key, but it is possible
to verify the identity if you know it, i.e. you know the private key.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 13 Oct 92 09:15:29 PDT
To: CYPHERPUNKS@TOAD.COM
Subject: Mail headers
In-Reply-To: <9210131201.AA12086@domingo.teracons.com>
Message-ID: <9210131622.AA25597@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Hugh's comments brought up a idea to me.

RFC 822 is the standard for the format of Internet mail messages.
Anybody interested in the remailer should eventually read this thing.

In it there is already a standard header field "Encrypted."  It
accepts two optional arguments, a decryption type and an identifier
(say, for key lookup).  So we have a way of automatically telling
encrypted message without doing pattern recognition on the body.

I propose a couple more header fields.  "Digest" for signed message
digests.  "Key-Mgmt" for the distribution of new keys and key
compromise certificates, i.e. for automatic key distribution.

What else do we need to make a fairly automated crypto mail system?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Tue, 13 Oct 92 10:53:19 PDT
To: Eric Hughes <hughes@soda.berkeley.edu>
Subject: Re: Mail headers
In-Reply-To: <9210131622.AA25597@soda.berkeley.edu>
Message-ID: <9210131800.AA10408@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


We have standards already for a fully encrypted email system.  It's
called PEM, Privacy Enhanced Mail.  It'd be completely senseless to come
up with a different format at this point, as PEM is on the verge of
deployment.

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Tue, 13 Oct 92 11:30:35 PDT
To: Hal <74076.1041@compuserve.com>
Subject: Re: Mr. Squirrel
In-Reply-To: <921013154244_74076.1041_DHJ92-2@CompuServe.COM>
Message-ID: <9210131837.AA28968@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



The most pressing thing is not to integrate encryptions in mail handlers,
but at the level of ether.  Ether is an enormous security hole.  I can walk
up to anything running ether with my notebook, plug in, and listen to all
traffic.  Therefore, ether cards need public key encryption built in, so
they can communicate with eachother in a secure way.  This also applies to
all other low level protocols.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 13 Oct 92 08:55:18 PDT
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Re: Mr. Squirrel
Message-ID: <921013154244_74076.1041_DHJ92-2@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


||ugh Daniel raises some questions about using public keys to
verify pseudonyms:

>   Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone
> can use any public key they want also.

But, once person A creates public key X, nobody else can sign messages
using X.  So if all messages from A are signed under X, we can know
that they are all from the same person, even if they are sent anonymously
or under a pseudonym.

> So, in a many-to-one scope (as
> in a maillist) where the sender can not use the one-on-one signed
> signiture method how do we have proff of who the sender really is?

You can use signatures even in a many-to-one scope.  Messages from
a particular person could be signed and the signature appended to
the message.  Then anyone who has the public key can check to see
who the message came from.  The process is a little unwieldy now
in PGP because you have to separate the signature and message into
separate files and run PGP on the signature file.  This should be
streamlined.

> [Good points about keeping track of key-pseudonym pairs]
> But all this needs to be done automaticly by the mailers and
> interfaces, else the system will be mis-used and folks will tire of
> the extra work that gets them little advantage.

Absolutely.  The most crying need now, IMO, is to better integrate the
cryptographic tools into mail readers and senders, so that it's not
such a pain to use these things.  People should be able to give a single
command or press a button to decrypt an incoming message or encrypt an
outgoing one.  Only then will these features be used by average people.

There was a message posted on alt.security.pgp describing how to
use PGP with the Emacs mail reading program.  I'd like to see more
messages telling how to use it with other systems.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Tue, 13 Oct 92 08:58:32 PDT
To: hugh@toad.com
Subject: Mr. Squirrel?  Just who is whom here?
In-Reply-To: <9210131201.AA12086@domingo.teracons.com>
Message-ID: <9210131550.AA03941@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: hugh@domingo.teracons.com (Hugh Daniel)

>  A second thing that Hal's comments bring up is that we were reading
>the From: headders and ignoreing the keys.  In good crypto-mail
>readers the key ought to be checked against our own data base of
>others keys and the result added to the hedders as say:
>	KeyCheck: FooBar Bazoid holds this key in XXX database
>or some such rot.  I wonder what is more important, who I claim to be
>in a random message or what key I include...

Anyone can include your key in a random message. If you just sign your
messages, then the whole thing goes away and everyone knows its from
you. PGP allows you to sign messages without encrypting them. The
problem is that most people find using PGP on routine email
inconvenient.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 13 Oct 92 11:49:36 PDT
To: cypherpunks@toad.com
Subject: Mr. Squirrel
In-Reply-To: <9210131710.AA20497@bsu-cs.bsu.edu>
Message-ID: <9210131856.AA29470@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



A signature on a message is dependent on the contents of the message;
it is not a free floating bit of information.  You can't copy a
signature, therefore, without copying the message or find another
message that hashes to the same value.  This is the design criterion
behind one-way functions--that you can't (feasibly) find a message
that hashes to a given value.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 13 Oct 92 19:52:16 PDT
To: cypherpunks@toad.com
Subject: Integrated privacy...
Message-ID: <2931.2ADB225F@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> Absolutely.  The most crying need now, IMO, is to better 
 U> integrate the cryptographic tools into mail readers and 
 U> senders, so that it's not such a pain to use these things. 
 U>  People should be able to give a single command or press a 
 U> button to decrypt an incoming message or encrypt an 
 U> outgoing one.

I just completed (well, it's in "beta") a mail-reader package for
MSDOS and FidoNet. It does "rm" type stuff, and has PGP integrated
reawonably well. Single character commands to decrypt, encrypt, sign,
or encrypt/sign. It furnishes the distributed PGP.EXE program with
it's imput (deriving it from the message itself). It'll extract keys
from messages, and all that.

It's MSDOS and .MSG-type FidoNet message base oriented, but it does
all it's work in pure ASCII (FidoNet .MSG files are mixed binary and
text). It is intentionally "RFC-822 like", and will become fully
RFC-822 "soon".

I was reasonably careful regarding de-cyphered plaintext laying about
on disk, etc. It's available via Wazoo filerequest as magicname RM.
(That's probably as obscure to you as FTP is to FidoNet.)

It will be released as "copyleft" with all sources. Binaries only
this week til I get it shaken down.


 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nowhere@bsu-cs.bsu.edu (Chael Hall)
Date: Tue, 13 Oct 92 10:04:24 PDT
To: cypherpunks@toad.com
Subject: Re: Mr. Squirrel
In-Reply-To: <921013154244_74076.1041_DHJ92-2@CompuServe.COM>
Message-ID: <9210131710.AA20497@bsu-cs.bsu.edu>
MIME-Version: 1.0
Content-Type: text/plain


>But, once person A creates public key X, nobody else can sign messages
>using X.  So if all messages from A are signed under X, we can know
>that they are all from the same person, even if they are sent anonymously
>or under a pseudonym.

     Who's to say that person B sees a message signed under X by person A.
He copies the signature (X) onto the bottom of one of his messages and
everyone thinks they can verify that it's from A but it's really from B.
(makes sense to me anyway...)

Chael Hall

Chael Hall                                   |     Campus Phone Number
iuvax!bsu-cs!nowhere                         |       (317) 285-3648
00CCHALL@bsuvax1.bitnet                      |
iuvax!bsu-cs!bsu-ucs!00cchall                | "I hate it when that happens!"




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Tue, 13 Oct 92 12:12:29 PDT
To: George A. Gleason <gg@well.sf.ca.us>, cypherpunks
Subject: Re: one time pads
In-Reply-To: <199210130821.AA03658@well.sf.ca.us>
Message-ID: <9210131912.AA14835@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


One time pads don't provide perfect security, George.  They only
provide perfect security if the opponent doesn't know the contents of
the pad.  Given that most small organizations are in locations that are
easily burglarized, ``when lives are at stake'' it would be easy for
governments to break in, copy the storage medium containing the pad, and
then read all past and future traffic encrypted with that pad.

All cryptography is economics.  If you make it harder to tap your phone
lines, but it's cheap to break in, they'll do that.  There is no absolute
security this side of the grave (and who knows about the other side).

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 13 Oct 92 19:52:16 PDT
To: cypherpunks@toad.com
Subject: PGP implementation for FidoNet
Message-ID: <2932.2ADB2261@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



There's a conference in FidoNet called PUBLIC_KEYS, devoted to PGP
and surrounding issues. Most evreyone is enthusiastic but without
security experience. As always, we find that the prevailing "right
ways to do things" don't fit.

FidoNet's main need is "privacy", not "Security". What would be
considered very low "security" in traditional circles would be more
than adequate. (And of course the usual ways work just fine with a for
"real" security needs.)

Follows is an article I ran in FidoNews, the weekly FidoNet
newsletter. I hoep it makes sense. The FidoNet environment is a
little different than other nets.






* Security and authentication using PGP in FidoNet

THOUGHTS ON SECURITY AND AUTHENTICATION
FOR EMAIL SYSTEMS
Tom Jennings (1:125/111)



Some ideas on public key security systems. To sum up ahead of time, I
assert that the public broadcasting of public keys is more than
enough security and authentication for casual, privacy needs in the
FidoNet or other email network.

All of this article assumes the use of PGP version 2.0, the RSA
double-key encryption system implemented as freeware.


This is all new to most of us, this security/privacy thing. Both
technologically and socially. What privacy we have we take for granted
without much thought; letters in envelopes, "who is it?" to knocks on
the door, etc. When we try to break down these things into their
underlying assumptions, well, it's hard. We shouldn't get upset with
ourselves or others if "we don't get it" right away. And we'll find
some obvious things aren't, and vice versa.

I will assume that if you really, really need utter absolute security,
you can achieve that with PGP or whatever. If it's that sensitive,
sending it over an electronic medium probably isn't recommended. This
article isn't about how to achieve bank-vault security.

Within the FidoNet, the most common use we all seem to talk about is
PRIVACY, rather than SECURITY. I can only speak for myself, but, my
netmail (not echomail) traffic is probably a reasonable example.  I
read about 100 messages a week, and send out about 50. There's a dozen
or so people I talk with regularly, and about 50 per week that I do
not know. Most of it is of the "Oh yeah, so and so said this. How's
your mother. Did you get that file OK...". Even if an eavesdropper
read this stuff, I would barely care. 

There are some times though when revealed message contents could be...
personally compromising. Embarrassing. A real life example: a long
time ago, a sysop in a net was having trouble with their net host.
Some messages critical of that net host were intercepted by the host,
some passed on, and some we each got replies to! Not Good. 

What *I* want is a way to ensure that sometimes, only the addressee
can read a given message. I am willing to pay some penalty for this,
but I won't live with a system that restrains me like a stone castle
and moat. My needs and risks just aren't that great.

With that as a background assumption, let's look at two separate
issues that look at first to be the same -- SECURITY and
AUTHENTICATION.


SECURITY -- given an encrypted message, how likely is it that someone
can ascertain what's inside it (assuming you're not the addressor or
addressee)?  As an operating assumption, I will take it for granted
that PGP produces files that are secure in themselves (barring bugs,
etc). Like the docs say, a frontal cryptological assault is hard, and
in our casual privacy case, probably not what we've got to worry
about.

There are other ways to figure out what's going on. Imagine you're
that net host. You've had trouble with this particular sysop before.
You notice he's just sent a flurry of messages to the local RC, then
the ZC. Hmmm!! Do you really need to know what's in those messages?!
(This is called traffic analysis. In pre-WWII Germany, the Nazis
tracked down "Jew sympathizers" with traffic analysis of telephone
billing information; Europeans don't get itemized phone bills any
longer... like here in the US. So I was told, the information is no
longer kept. (Do I really believe that...:-))

Anyways, security is more than cryptographic strength. Turns out,
there's a way around this: anonymous remailers. In a private Internet
mailing list Eric Hughes came up with a trick to anonymously remail
messages; you send mail destined for system X to the remailer instead;
it strips off the header info and mails it to system X.  Anonymity
isn't really needed though in the case above, simple remailing will
do. Again, our *general* FidoNet needs are modest.



AUTHENTICATION is the sticky one for us. Authentication is
determining: is this person really the person they say they are? But I
think you'll see it isn't the fatal problem it appears to be at first.

Let's get the obvious case out of the way first again: if you need
utter and absolute security, you better damn well know the person
ahead of time, you should get a key delivered by hand, and you should
think about if you really want to conduct business over an electronic
link in the first place. Authentication in this case isn't -- or
shouldn't be! -- a problem.

For our relatively-casual privacy use, authentication is almost moot.
Some people I have already exchanged keys with, *I've never met face
to face in my life* and may never. In spite of this I feel I know
them. I trust or assume that they are who they say they are. This is
the environment we need to work in.

This, plus the fact that we've got (at the moment) some 16,000
potential keys, means we simply can't do the full-blast security
thing. How much "security" can I expect, or need, with someone I've
never met? Consider again the utter-security case again.

But the bottom line is in fact already taken care of, PGP or not --
how do you know that "the real Tom Jennings" wrote this article? Our
underlying social system, so frequently overlooked, takes care of it.
You can assume I, and many people who have been in the net, are
verifiable. You have a number of ways to determine if I really wrote
this article. Simply asking via FidoNet will uncover most fakes.
Looking at old nodelists to see what info on my name has changed. Ask
people who might know me. And so on. 

If our public keys are scattered to the wind like plants scatter
pollen, it is certainly possible that I could fake "your" public key,
and gain access through all the methods discussed in detail in the
literature.  However, assuming the real person and the fake person(s)
are both generating keys (and using them to sign and send messages),
the more keyrings were passed around the chances of detecting the
incompatible keys becomes almost certain. At that point, even a casual
effort would be able to track it down, to at least determine that
there *was* a fake.

Example: Mary has been using PGP for a few months, and conversing with
friends and acquaintances. Her public key is filerequestable, and
probably appears on a hundred keyrings. 

Over the next few months, other people get messages from "Mary" making
increasingly odd claims, via encrypted mail. The impostors fake key,
in order to be useful at all, would also have to be widely
distributed.

Curious, someone sends Mary a message encrypted with what appears to
be her public key, and a plaintext one telling her that the
cyphertext was encrypted with her public key, and that he suggests if
she can't decipher it someone may have faked her key.

What Mary actually does depends on many things. If she has indeed
been creating the crazy messages, well, the problem's elsewhere. If
she finds she can't read the message, her recourse depends on what is
available to her: if there are public key repositories, she would be
advised to contact them and notify them of the alleged faked key(s),
and follow whatever process is setup to generate a new key.

The very knowledge of key collision would be enough to flag to users
that there's a potential problem.


There are more practical issues that limit our need for traditional
security measures on keys.

Even if you stored your private key on disk, it would take physical
access of your machine to get it. This is not what I'm worried about
in private FidoNet mail. If a FidoNet member tries to break into my
house or system to get at my key, I've got other troubles! 

Practically speaking, it might even be a good idea to have two keys; a
small (256 bit) one for casual, email privacy, and a big one (1024
bits) that you give to people by hand on diskette. The small key will
mean better performance, more important on bulk casual email, and
certainly adequate against eavesdropping. For high-security needs,
which most people don't have (I certainly  don't), the performance
penalty probably won't matter as much.

The worst part of security systems is that people will *rely* on them
as absolutes. This is the only thing that makes a faked, encrypted
message worse than a faked, plaintext message.

Again, it's important to remember the goal (as if we could ever
possibly agree to a *single* goal...) -- if it's privacy, the ability
to stop eavesdroppers, then a broadcast public key system is more than
adequate, and public key repositories even better. If you want a
maximum-security vault, you take added precautions. No one system will
solve all problems. I'm a firm believer in a broadcast public key
system for email.



PRACTICAL SUGGESTIONS FOR PGP USE IN FIDONET PRIVACY:

 * Use small (256 bit) keys for routine, low-security use, such as
netmail privacy with people you don't know personally (and don't get
keys from physically).

 * Public key encryption is most useful for email, ie. FidoNet
netmail, especially when it flows through multiple hosts on its way
to its destination.

 * The current password scheme for echomail links is proven to be
adequate to safeguard what is basically a public forum, anyways.
Further security doesn't seem to be needed on these links.

 * When adding keys received via FidoNet to your public keyring,
answer "do you want to certify this key yourself" with NO, unless you
received the key by hand. It doesn't hurt the usefulness of the key
itself; however, if someone later uses your public keyring they won't
be lulled into a false security. (Certification of keys can be done
at any time.)

 * Passing keyrings around willy-nilly, though counter to "good
security practice" in traditional uses is actually a good thing for
us. "Key Repositories" scattered throughout the net (each exchanging
keyrings as well as posting lists of "trouble keys") is a better idea.

 * Reserve large (1024 bit) keys for people who you know, and can
ensure security in traditional ways (some pointed out in the PGP
documentation). 

* As seems to be developing, have your public key filerequestable as
magicname "PGPKEY" (your own public key only), and your keyring as
"KEYRING" (all of your public keys). These should be ASCII-armor
files (PGP -kxa)


 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Fen Labalme" <fen@genmagic.com>
Date: Tue, 13 Oct 92 15:56:27 PDT
To: "Cypher Punks" <cypherpunks@toad.com>
Subject: anonymous bank accounts via
Message-ID: <9210132256.AA08647@relay2.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


Mail*Link( Remote             anonymous bank accounts via pem

FYI:

[pem-dev is a private email list for developers of the Privacy Enhanced
Mail protocol additions to Internet mail, originally published as RFCs
1113 - 1115, and now updated as four draft-ietf-pem documents.  To join
the list, send email to pem-dev-request@tis.com.  By the way, most of
the discussion is not nearly as germane to our ideas as this particular
posting, but this one caught my eye as of some iterest to cypherpunks.]

----------- Forwarded Message ------------

Date: Tue, 13 Oct 92 01:07:39 EDT
>From: uunet!ellisun.sw.stratus.com!cme (Carl Ellison)
To: pem-dev@TIS.COM
Subject: Re: [Peter Williams: Perhaps OSI security is not possible in a liberal
community!]
Sender: uunet!TIS.COM!pem-dev-relay

Let me throw in another vote against the *necessity* of hierarchical
certification by arguing against the necessity of certification itself.

For example, it is possible, given digital signatures, to have totally
anonymous bank accounts -- identified only by public key -- with no
certification of relationship between that key and any other fact about any
individual or corporation.  Such accounts are at least as valuable as a
Swiss numbered account -- perhaps more so since no one need know the
identity of the person or people with the power to withdraw funds.  Such
funds transfers can be made not only anonymously but untraceably.  It might
even be possible for them to be made without it being possible to trace
the transfer at either end (eg., using digital cash techniques).

I don't propose that all bank accounts be anonymous.  It's just that I
don't like to see us jump into an attempt to relate public keys into the
physical world so that our old established notions about relationships and
responsibility can carry over into this new domain when by doing that we
end up avoiding research into all the possibilities which digital
signatures open up.  That research needs to be both technical and social --
or we could shy away from it by forcing relationships between keys and
those entities to which we are already accustomed.

--Carl






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Tue, 13 Oct 92 13:46:27 PDT
To: Eric Hughes <cypherpunks@toad.com
Subject: Where to get further information about PEM
In-Reply-To: <9210131853.AA29373@soda.berkeley.edu>
Message-ID: <9210132046.AA19146@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


Get the latest Internet Drafts for PEM; the RFC's are out of date.

By ftp to nic.ddn.mil, directory internet-drafts:

-rw-r--r--  1 gvaudre  35978 Sep  4 03:36 draft-ietf-pem-algorithms-01.txt
-rw-r--r--  1 gvaudre  16031 Sep  2 03:36 draft-ietf-pem-forms-01.txt
-rw-r--r--  1 gvaudre  85132 Aug  7 03:30 draft-ietf-pem-keymgmt-01.txt
-rw-r--r--  1 gvaudre 104515 Jul 25 03:30 draft-ietf-pem-msgproc-02.txt
-rw-r--r--  1 gvaudre    128 Sep  2 03:36 draft-ietf-pem-notary-00.txt

	John

PS:  I too think that other key certification models besides "hierarchical"
are appropriate.  I think we can start from PEM software and PEM message
formats and evolve and experiment as appropriate.  Before you ask, currently
there is no PEM software widely available.  It's in alpha test.  It will
be released in full source code, and its development was funded by DARPA.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Tue, 13 Oct 92 13:25:13 PDT
To: gnu@cygnus.com
Subject: Mail headers
In-Reply-To: <9210131800.AA10408@cygnus.com>
Message-ID: <9210131851.AA07309@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: gnu@cygnus.com

>We have standards already for a fully encrypted email system.  It's
>called PEM, Privacy Enhanced Mail.  It'd be completely senseless to come
>up with a different format at this point, as PEM is on the verge of
>deployment.

One might have a good reason to follow most of PEMs formatting
standards and the like; I'd fully agree its foolish in the extreme to
do otherwise. However, some of us don't like PEMs hierarchical key
authentication concepts.

Perry






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 13 Oct 92 13:37:43 PDT
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: New remailer...
Message-ID: <921013203148_74076.1041_DHJ21-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


I have been experimenting with Eric's remailing software on
the Sun 4 I use at work.  This is what I've found.

First, Eric's descriptions of how all the different software
components work together have been very helpful.  The software
has gone through three revisions as Eric added new features, so
I implemented them in that order - first the basic remailer,
then adding the "##" and "::" support for header management.

(I had to get perl and slocal before I could get started.
Luckily my system already uses sendmail.)

Basically, I was able to put the parts together the way Eric
described and have it work.  I was able to send messages and
have them remailed.  I even did some tests bouncing mail between
my remailer and Eric's.

Then I tried adding a new feature to the remailer - automatic
message decryption using PGP.  It's not really very secure since
anyone with root privileges at my site can see my pass phrase,
but my site is pretty isolated (a 2400 baud modem is the only link
to the outside world).  For this I had to add one line to Eric's
model .maildelivery file to invoke my PGP filter, and had to write
about a five line shell script to run PGP in a useful way.  I
am still tuning this a little bit but I can send the exact scripts
out when people are ready for them.

One nice thing about this is that, with my remailer plus Eric's,
and with the decryption option, you can now send anonymous messages
for which no one person can tell that you did it.  What you would
do is to send the message first through Eric's remailer, so I
don't know where it came from, then through my remailer, but with
the message encrypted so that Eric can't tell where it's going after
it leaves me.  If more people will run remailers then we'll have
much more security.

I will now tell you how to use it, in case you want to experiment.
But remember that all messages are going across an intermittently-
polled 2400 baud modem, so don't expect fast turnaround and please
don't send a large volume of messages.  Also, please don't pass
information about this remailer beyond this list, for now.

The remailer is at hal@ghs.com.  The basic remailing operation is
as Eric has described: either put "Request-Remailing-To: <dest>" in
the header of the message, or put, as the first two lines of the
body of your message:

::
Request-Remailing-To: <dest>

And follow these two lines with a blank line, then the message to
be forwarded.

Decryption is just a little complicated.  The thing to remember is
that you want to do more than just have me decrypt the message.  You
want me to then remail the message after decryption.  This means
that you should prepare a message with remailing instructions as
above, then encrypt the whole thing, including the "::" and
"Request-Remailing-To:" lines.  Encrypt using PGP with the public
key I show below, and use the -a flag for Ascii output.

This will create a PGP output file, typically with the extension .asc.
The first line will be:

-----BEGIN PGP MESSAGE-----

Now, you can send this message to me, but you have to do one more
thing.  You have to mark it as an encrypted message, by putting the
line "Encrypted: PGP" in the header.  If you can't put stuff into
the headers of messages, then use Eric's "::" feature and add the
following two lines, then a blank line, before "-----BEGIN PGP MESSAGE-----":

::
Encrypted: PGP

Don't forget the blank line after these two.

Now, this message can be sent to my remailer.  It will be decrypted
and then remailed to whomever you requested.

I know this sounds complicated, so let me break it down into steps:

  1. Create the message.

  2. Add "::" and "Request-Remailing-To: <dest>" and a blank line to the
	top.

  3. Encrypt the whole file using PGP and the public key below.

  4. Add "::" and "Encrypted: PGP" and a blank line to the top of
  	the encrypted file.

  5. Send it to hal@ghs.com.

That's not so bad, is it?

Now, if you're really adventurous, here's how to do the double-remailing
process I described above, the one which keeps any one remailer from
knowing who's talking to whom.

  1. Create the message.

  2. Add "::" and "Request-Remailing-To: <dest>" and a blank line to the
	top.

  3. Encrypt the whole file using PGP and the public key below.

  4. Add "::" and "Request-Remailing-To: hal@ghs.com", then a blank line,
  	then "##" then "Encrypted: PGP", then a blank line, to the top of
  	the encrypted file.
  
  5. Send it to hughes@soda.berkeley.edu

The only complicated step is step 4, where you put in the remailing
request to go from Eric's system to mine, and use the "##" line so
that the outgoing message has "Encrypted: PGP" in the header.

If you want real security, encrypt the message using your friend's
public key after step 1 and send that.  Then nobody will even know
what you're saying, let alone who you're talking to.

As promised, here's the public key for my remailer:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.01

mQBNAirY9EoAAAEB/iuDBqpeJ8gsNQwJNRYWBxH7uP95ApQ92CDhCmuSEJ0Tta0l
oCrC+8Br+D7Nfotb7hJlI0A1CYGAlmCsRO8VEmkABRO0H1JlbWFpbGluZyBTZXJ2
aWNlIDxoYWxAZ2hzLmNvbT6JAJUCBRAq2ISQqBMDr1ghTDcBARYlBADCjkCkIDvA
7QFtpYUlYjz/2U+/oDuMZBDlmAw8BCg3sdJG7hnxPE4yVgKoH/ozsb23pbFTPB8H
WNEjqTqixNybOKSKH9T8iCaRDA8+bS6xPN4YlWKD/Wg2EiyuOjD3v/vWgiZXzMR5
hpe0CYVJ6bM++hptXu+JxqDReJIot5FFbQ==
=p8FS
-----END PGP PUBLIC KEY BLOCK-----


Hal
74076.1041@compuserve.com

P.S. Coming soon: anonymous return addresses!





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hugh@domingo.teracons.com (Hugh Daniel)
Date: Tue, 13 Oct 92 18:58:39 PDT
To: cypherpunks@toad.com
Subject: Matching Text, Headders and Signatures with Crypto Hashes
In-Reply-To: <9210131710.AA20497@bsu-cs.bsu.edu>
Message-ID: <9210140150.AA12409@domingo.teracons.com>
MIME-Version: 1.0
Content-Type: text/plain


  A genral and powerful method of makeing sure that Headders, Bodys
and Signatures match is to use cyrpto-checksums.

  For example in NetNews I proposed changing the MessageId: headder
such that part of the gobldyguk on the left side of the atsign was a
crypto hash of the body of the message and some of the important
sending host generated headders.
  With this system of MessageId:'s anyone who corrupts a message
(intentionaly or otherwise) creates a bogus message, as the next
machine that gets the message can see that the message does not match
it MessageId: line.

  So, if we design the signature system right (with a field for a
crypto hash, or some sort of secondarys signatures to in efect counter
sign various includes such as the plain text) a plain text message can
be signed in such a way that you can be sure that the text is the
right text and none other.
  This can be sent over the airwaves as it is not hideing information
but proveing that it is the right information!

  Systems like this would be *very* usefull right now, are simple to
do (with good advice from Crypto Math types) and usefull to everybody.

		||ugh




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 13 Oct 92 22:45:57 PDT
To: cypherpunks@toad.com
Subject: re: Re: Mr. Squirrel
Message-ID: <2934.2ADBB27E@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain




 U> The most pressing thing is not to integrate encryptions in 
 U> mail handlers, but at the level of ether.  Ether is an 
 U> enormous security hole.  I can walk up to anything running 

Who uses ethernet?!  :-)

I think it's safe to say our FidoNet doesn't have three feet of
thinwire in it. We're all dialup. Message-reader integrated security
is where it's at -- here.

You're totally right about it though... but it requires physical access.


 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 13 Oct 92 22:45:57 PDT
To: cypherpunks@toad.com
Subject: re: Matching Text, Headders and Signatures with Crypto Hashes
Message-ID: <2936.2ADBB282@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: hugh@domingo.teracons.com (Hugh Daniel)

 U>   For example in NetNews I proposed changing the 
 U> MessageId: headder such that part of the gobldyguk on the 
 U> left side of the atsign was a crypto hash of the body of 
 U> the message and some of the important sending host 
 U> generated headders.   With this system of MessageId:'s 
 U> anyone who corrupts a message (intentionaly or otherwise) 
 U> creates a bogus message, as the next machine that gets the 
 U> message can see that the message does not match it 
 U> MessageId: line. 

There's a FidoNet mailer (Dutchie) that uses MD4 to generate message
IDs in exactly this way... They did some cheat, to allow certain
filters (CR/LF vs LF, etc) to work.

 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wixer!pacoid@cs.utexas.edu (Paco Xander Nathan)
Date: Wed, 14 Oct 92 03:49:44 PDT
To: cypherpunks@toad.com
Subject: Game items
Message-ID: <9210140517.AA12767@wixer>
MIME-Version: 1.0
Content-Type: text/plain



Just about any device for refining psychoactives...  Alcohol stills, for one.
We run one at home in TX, legal now, but which would have been jailbait in my
grandmere's time.

In certain parts of TX, wirecutters used to be illegal on strangers.  They
implied cattle rustling, etc.

Phone recording equipment is legal now in many areas - formerly forbidden by
wiretap laws, but now available through catalogs like Damark, etc.

It would be so easy to find counter examples - non-weapon, physical items
formerly legal, now illegal or heavily watched/licensed...  precision scales,
lab glassware, Kevlar, radio transmitters...

pacoid.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Judith Milhon <stjude@well.sf.ca.us>
Date: Wed, 14 Oct 92 10:28:10 PDT
To: cypherpunks@toad.com
Subject: game items
Message-ID: <199210141727.AA18138@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



You needn't timetravel to come up with instances of underground heroism.
There is RIGHT NOW an underground dealing with AIDS meds. And there may be,
soon, an RU-486 network. <Bruce Sterling is publishing a very funny story
about this called Are You For 86?> These are worlds away from traffic in
sleazy recreationals for profit.

<Sounds even PC, ne? Of course, illegal and sleazy shd be clearly
distinguished. How about LEATHER GOODS? Heh: nasty costumery, best advanced
designs. Slings if not arrows of outrageousness. Branks, quirts. Hee.>

<Keep in mind that this is meant to be an involving GAME. Games should be
FUN. More whimsy, yes?>


>jude<




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Wed, 14 Oct 92 17:26:19 PDT
To: cypherpunks@toad.com
Subject: illegal objects
Message-ID: <2952.2ADC70A6@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Hell, there's real-world examples today that some of my friends have
been harrassed for: "Obscene materials".

OK, sexually explicit photographs are a trivial example. Friends have
gotten harrassed (by US customs) for zines containing weird shit, not
just sexually explicit. The US/Canada customs people are living in
another century and reality plane.

 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 14 Oct 92 11:06:29 PDT
To: cypherpunks@toad.com
Subject: Some (Pseudo)Random Thoughts
Message-ID: <9210141805.AA04539@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Some thoughts on the recent meetings and what we're doing:


1. The importance of trading physical goods in the Crypto Anarchy
Game.

This, in my view, has been given undue and misleading importance.
Physical goods are inherently easy to trace through remailers (via
sniffers, radioactive tracers, weight of packages, and many other
physical cues), are hard to store physically (imagine getting 100
parcels for later remailing), and, most importantly, have none of the
"envelope within envelope within...." protection accorded to the bits
of a cryptographic remailing, or DC-Net, system! The elegance of
cryptographic protocols is lost with physical goods.

Furthermore, physical delivery of any good, whether drugs, stolen
missile components, antiquities and art items, whatever, is
fundamentally a hard problem to solve...smugglers and thieves have
been dealing this since the beginning of time. Stings can be easily
arranged, delivery is not anonymous (one merely watches who takes
delivery, or who opens a train station locker, etc....this is all SOP
for narcs and counterespionage types), and a raid on a remailing
entity will result in confiscation of the physical goods and (likely)
prosecution of those caught holding the stuff. (Raiding a bit
remailing entity produces only random-appearing bits...granted, the
authorities may well outlaw bit remailing, or use the RICO and
conspiracy/sedition laws to prosecute, but that's another topic.)

Our recent emphasis on physical goods, and all the ideas pouring in on
what other kinds of "contraband" besides drugs can be used, is
misleading. None of the richness of the cryptographic world is
faithfully preserved. I urge we get back to our roots and deal only
with things that can be expressed purely in bit form. 

2. The "colonization of cyberspace" does not mean there is no
interaction with the physical world, of course. But that interaction
can be mediated with money made by converting information or digital
money into physical money. Several methods for this conversion path
can be considered:

-Alice sells information in the cyberspace domain for the equivalent
of, say, $30,000. She converts this to "real" dollars by using an
escrow entity which hold both sides of the transaction until it's
completed. They then mail the information to the purchaser and send an
ordinary check "for services rendered" to Alice for $30K. She reports
it on her taxes, probably as a "consulting fee" (for which essentially
no government supervision currently exists, nor is likely to....), and
the conversion has taken place.  (Note: there are still elements of
trust involved, notably involving the escrow agent, but trust works
pretty well for many things, especially when reputations are at
stake. Understanding how real businesses depend on reputations is a
missing part of modern cryptology analyses of transactions...the
protocol analyzers and number theorists almost never take into account
how reputations work in the real world, But I digress.)

-Alice and Bob trade information such that Bob gets the information
worth about $30K, as above, and Alice gets another piece of
information she can use in the "real world" that is worth about $30K.
This might be stock tips, or, better, information she can turn around
and sell in the "open market" of a service like AMIX!  There are lots
of wrinkles, inefficiencies, etc., to be worked out.

-And then there is digital money. You all know about this, or should.
David Chaum, DigiCash, blinded notes, credentials, etc. The handout
for the first meeting had a glossary of terms. (IMHO, we should be
spending more of our time at our meeting discussing this, and less in
playing more interations of the Game.)

The fascinating novel "Snow Crash," by Neil Stephenson, makes a
mistake in having Hiro Protagonist a very wealthy man in the Metaverse
(Stephenson's term for the virtual reality cyberspace) but a very poor
man in the Real World. Information _is_ money. Information is liquid,
flows across borders, and is generally convertible into real money.
(One simple conversion strategy, alluded to above, is for Alice to
sell her information for, say, $500K, and then to receive a
"consulting contract," perhaps called a "retainer," of $50K a year for
the next 20 years. Her retainer is fully legal, is perhaps handled
through cut-outs who specialize in this kind of thing, and is a
low-risk way to "launder" money from cyberspace into the real world. I
have a lot more to say on these schemes, perhaps later.)

3. Are we emphasizing "The Game" too much?

If the goal is to produce a paper-based game, similar to "Monopoly" or
fantasy role-playing games, then I suppose more practice is needed.
But I'm not sure how worthwhile it is to try to design such a game.
(Those who wish to should do so, then commercialize it, and become the
Avalon Hill of crypto games!)

If the goal is educational, for newly interested folks, then I also
question how much more effort should be put into it. The ideas of
anonymous remailers, of digital money, etc., are, I think, gotten
across in the first 60 minutes of the game, especially if some of the
formalism is first explained (as it was at the first game, where
digital mixes, tamper-resistand modules for implementing mixes, the
"Dining Cryptographers Protocol," and digital money had all been
freshly covered, so participants were putting the theory to test).


I found the first game was instructive, the second much less so (and
_not_ because of the focus on drug selling...that was a relatively
minor issue). My impression is that many of the newcomers--and they
should jump in here with their own reactions (too bad we don't have
hypertext links!)--didn't really know how remailing mixes work, how
digital psueodnyms can protect privacy in transactions, and how the
"Game" was intended to exercise these concepts.

4. We need to talk about the charter or purpose of the "Cypherpunks"
or "Cryptology Amateurs for Social Irresponsibility" (CASI--Eric
Hughes's term) group.

-Is it mostly educational?
-Is it a lobbying group, as are EFF, CPSR, and the like?
-Is it to produce remailers, digital money, and other programming?
-Is it subversive?

Now clearly we can't say it's subversive (any bets on who's gatewaying
these messages to Other Listeners?). But we also don't want to skew
things toward "YALG" (Yet Another Lobbying Group), nor do we want to
be a spoon-feeding educational group for people with a casual (and
transient) interest in crypto stuff.

5. There have have been several messages so far about worries about
the legal implications of these topics, about how some
corporate-affiliated subscribers will desubscribe "real fast" if
certain discussion trends continue, and so on. Now we can't please
everybody, but maybe we ought to talk about this sensitive issue soon,
and _in person_.

Since it relates to our charter, Point 4 above, I recommend we do this
at our next meeting. I'd favor that over another iteration of the
Game.

In conclusion, we are in at the beginning of Something Big. While I'm
somewhat skeptical about the claims for things like nanotech, I see
this whole cyberspace/cryptology/digital money/transnationalism ball of
wax being _much_ easier to implement. Networks are multiplying beyond
any hope of government control, bandwidths are skyrocketing, CPUs are
putting awesome power on our desktops, PGP is generating incredible
interest, and social trends are making the time right for crypto
anarchy.

I look forward to hearing your views.


--
..........................................................................
Timothy C. May | Crypto Anarchy: encryption, digital money,
tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
408-688-5409 | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Wed, 14 Oct 92 11:11:49 PDT
To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings)
Subject: Re: Mr. Squirrel
In-Reply-To: <2934.2ADBB27E@fidogate.FIDONET.ORG>
Message-ID: <9210141810.AA14191@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>Who uses ethernet?!  :-)

Everyone here at UC Berkeley.

>I think it's safe to say our FidoNet doesn't have three feet of
>thinwire in it. We're all dialup. Message-reader integrated security
>is where it's at -- here.

In the case of FidoNet, it sounds like that's what's needed, because your
mail is being sent from systems that are not multiuser systems.  The net
really is just for exchanging files and mail; it isn't for remote computer
access.

>You're totally right about it though... but it requires physical access.

Physical access is much easier than people think.  I can walk into almost
any computer room here at UC Berkeley and plug in.  And we have something
called building ether in the building I work in:  all of the machines in
this section of the building are on the same ether net.  This means that if
we want to see other researchers' data before it's published, we can,
because we can see all of their packets.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Wed, 14 Oct 92 08:27:57 PDT
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Game items...
Message-ID: <921014151922_74076.1041_DHJ62-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


I'm trying to think in terms of things which were illegal but
which have good moral connotations today.

Crosses and other Christian symbols were supposedly outlawed
during the Roman empire (leading to the adoption of the fish
as a symbol of Christianity).  Posing as early Christians smuggling
crosses ought to make the right-wingers happy!

Abolitionists had to smuggle runaway slaves out of the South
on the so-called "underground railroad".  Perhaps cryptography
would have helped them coordinate their efforts.

Much of the support in the U.S. for freedom and privacy comes from
our revolutionary heritage.  I'm embarrassed at how little I can
recall of what things were restricted in those pre-revolutionary
days.  I recall the Stamp Act and a few other laws, and I imagine
that seditious materials were restricted.  Perhaps the game players
could be early revolutionaries trading items forbidden under British
rule.

Hal Finney - 74076.1041@Compuserve.Com

-----BEGIN PGP PUBLIC KEY BLOCK-----
mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
=fF6Z
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hkhenson@cup.portal.com
Date: Thu, 15 Oct 92 03:39:36 PDT
To: cypherpunks@toad.com
Subject: Re: Game items...
Message-ID: <9210150128.1.14673@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


     I have not been paying enough attention to the cyberpunk list,
but I did notice that some of you were concerned with the subject, and
that Tim May was mentioning "pure information" as a better model to
play with, so I thought I would send this in as a sample.  Perhaps
some ideas of where to take the story will come out of using this 
model for another game.  Anyway, this game theme should not push as 
many hot buttons as drugs do (though it should!). 

     This fragment of a tale was written shortly after I came back 
from the first Computers, Freedom and Privacy conference.  It is 
placed in the time period between now and the usual time frame of 
Gibsonian cyberpunk.  It was written to help me think about the social 
& legal responses we might see when encryption is more widely 
available-- and used.  Sorry the story is incomplete, I just got too 
busy to finish it, and ran short of ideas as well.  And sorry for the 
obsolete technology involved.  I am sure something better than MS DOS 
will come along eventually.  :-)

(The usual conditions of posting apply--copyright H. Keith Henson 
1991) 
                


                Green Rage  by H. Keith Henson

     "'Nother hour and I can 'crypt and email this mess."  

     Lenny closed the forth of five files: maps, diagrams, schedules, 
assignments, and instructions.  It was a four person monkey wrench 
project for destroying a big piece of a paper mill and (he hoped) making 
it look like an accident.  It was due to take place on the east coast in 
a few weeks.  Lenny had never met any of the people who had scouted out 
the plant, nor the bitter, out-of-work engineer who had figured out how 
to wreck it, and none of the operators who were involved would meet each 
other.  Made for hard-to-crack operations.  Some people on the east coast 
did the same for the covert side of the GreenRage group that paid Lenny. 

     The tofu sandwich he had for breakfast was a dim memory.
 
     "Lunch first." Lenny thought.
 
     As he headed out to pick up a vegetarian pizza, he looked through 
the little glass panels in the front door. 
      
     "Oh, shit, suits outside,"

     Lenny said it with feeling, but kept his voice down.  He turned on 
his heel in the hall leading to the front door and ran back into the 
grubby GreenRage office in the dining room of a rented house in San 
Samon.  He managed to hit the power switch on the PC at Stel's desk 
before the door opened.  Stel was in the bathroom.  Whether she heard the 
warning or not, Lenny could get no help from her, and Marge was out on 
errands.  The door was opening--there was no chance to get to the other 
two computers or to take down the '586 file server in the kitchen--he 
looked up and in his best bright and cheerful voice (which to Lenny 
sounded hollow and rehearsed) said, "May I help you?" 
    
      The first of the four suits, a beefy dude in a grey outfit spoke up. 

     "Yes, you can.  We're from the CCA.  (The Computer Control Agency):  
We have a court order to copy all the computer files in this building," 
(he held up an official looking piece of paper--more trees destroyed, 
thought Lenny.) "so unless you want to be charged with contempt, you can 
step back from that computer, and don't touch anything till we are done." 

     Lenny stepped back.  He wasn't as terrified as he could have been, 
though his heart rate must have been close to 120 and his mouth was dry. 
He had been through raid drills and a few real confrontations with the 
law at pickets and bleed-ins. 

     "At least it isn't a search warrant, we might keep operating" he 
thought.  Then remembering the drill, spoke up: 

     "Can I see the order?"  

     The beefy one handed it over while his three leaner and younger 
companions fanned out to the computers.  They obviously knew where the 
computers were, but that did not necessarily mean rot in the 
organization.  How well they coped with the 'puters would say something 
about that. 

     The paper was about what he expected, an order signed by a judge to 
copy every storage device in the GreenRage's office to an encrypted WORM 
drive.  The box for paper documents wasn't checked, so they knew they 
wouldn't find anything useful on paper.  Bad sign, it meant they knew 
more about GreenRage than Lenny liked.  "Waste as much time as I can," 
Lenny thought to himself, and in a very polite voice he asked:

     "Can I see some ID for you and your men? 

     The closest of the technoids, as Lenny thought of them looked up in 
disgust after putting his hand on the back of the ancient '386 clone 
Lenny had just killed.  

     "Its been turned off in the last 2 minutes.  Did you do it when we 
came in?" he said this looking right into Lenny's eyes, while digging out 
his badge. Lenny didn't lie with his reply, 

     "Its Stel's, she was about to go out, and we try to save power by 
turning them off when we go out."  He said this as loud as he dared, 
hoping that Stel would hear him in the bathroom, then spoke up even 
louder, 

     "Stel, we have official visitors, so don't make any sudden moves." 

     At 200+ pounds, and fifty plus years, Stel didn't make many fast 
moves, unless they were on young guys.  In view of the constant water 
shortage, the chances were only about one in four that she would flush 
the toilet, and less than even that Stel would wash her hands.  Without 
any running water sounds, she come out. 

     "Pigs, huh."  Stel had been politically imprinted as an anarchist at 
Madison over thirty years ago in the late '60s and early 70's.  When it 
suited her, she could be one of the most obnoxious people Lenny had ever 
known.  At least it diverted the attention from him, chances were low 
that the cops would grill Stel on who shut off the power on her computer. 

     Beefy, whose' badge claimed to be one Dan Barker, and technoid #1 
(Lenny never did get a name for him, flashed their badges. Lenny grabbed 
a whiteboard marker (almost dry, and the only non computer writing device 
permitted in the office) and scribbled Barker's name and badge number on 
the edge of a badly cluttered whiteboard.  The other two technoids had 
fanned out, one to Lenny's desk, and the other to the kitchen.  The 
kitchen one came back shaking his head. 

     "No damn keyboard or display on the server.  Have to go in through 
the other ones to dump the disk." 

     Technoid #2 moved the mouse on Marge's machine, but thank the green 
mother, thought Lenny, the screensaver program had timed out, and the "I 
NEED A PASSWORD!" message came up.  That meant the password was gone from 
memory on that machine.  Technoid #3 hit paydirt on Lenny's machine: the 
screen was still alive.  He hit the space bar, and pulled out a little 
alarm timer which he set to go off every 3 minutes. "Damn, damnit" 
thought Lenny, "I should have set the timeout shorter, has it really been 
less than 5 minutes since I got up?"  And he was mentally kicking himself 
for not wiping the password when he got up. 

     Technoid #3 noted the directory (ACIDRAIN/TRMINATE) where Lenny had 
been working and went back up, a level at a time to the main directory on 
the file server.  He seemed prepared to deal with a no printer machine, 
pulling out a pad of paper from a little portfolio (more trees!) and 
started making notes on the directory structure. 

     Technoid #2 looked up from Marge's machine and asked Lenny, 

     "I don't suppose you would know the password?" 

     Lenny shook his head and then looked the agent in the eye.

     "No sir! I certainly wouldn't know Marge's password to get into her 
personal machine!" And wouldn't admit it if I did know, he thought. 

     Technoid #2 looked over at Stel frowning at the machine on her desk 
and asked mildly, 

    "I don't suppose you would remember your password?" 

    "Fuck off sharp one," Stel said with a straight face.  Even in a near 
state of panic, Lenny got a flash of amusement as Beefy started to spit 
out a hot reply.  Beefy checked himself as he saw #2 write down 
fuckoff#1.  Stel grinned slightly; she had almost scored one on the 
agents. 

    Without making a move toward Stel's machine, #2 asked #3, 

    "Shall I try it, Jim?"  Jim was engrossed, paging through directories 
but he mumbled: 

    "No, let's see what I can get before we risk a password given under 
duress." And, half a minute later, 

    "This is going to be a bitch, I can't find any programs to dump 
memory, no debug, no basic, no smalltalk, no turbo, nothing."  Lenny 
grinned, and straightened his face with an effort.  The crypt program had 
come with instructions to delete or encrypt under a special key a long 
list of compilers and interpreters-- not that he understood exactly what 
they were anyway. 

     "Bob, could you have one of the uniformed officers get the camera 
out of the car?  Looks like we are going to have to photograph some of 
this."  Beefy went to the door and tried to get the attention of one of 
the uniformed cops that had come with them.  No luck, they were both out 
back, keeping an eye on the building power switch so no one could turn it 
off.  It was less distance to the car, so he just walked out to the car, 
rummaged around in the back seat and brought back the camera kit.  Jim 
waited for him, typing a space every 3 minutes. 

     "Take it easy on the polaroid, damn film costs two dollars a shot," 
as he handed the camera kit to technoid #3.  Technoid #2 came over to 
help and started clicking shots of the screen as Jim worked his way 
around in the directory tree.  There were *lots* of interesting directory 
and file names.  Stel, Marge, and the three masked visitors from back 
east had spent a whole evening making up provocative names like HIT_LIST 
(Lenny's address book), and $LAUNDRY (data for a spreadsheet program 
Marge used), and a lot of disaster names like HINDENBG, and TEX_CITY.  
Since the crypt program left the directories in the clear, they thought 
they might as well make them amusing.  At the moment, with cold sweat 
dripping down his back, Lenny wished he had made the directories a little 
*less* provocative. 

     Once in a while, technoid #3 or Jim as Lenny was beginning to use to 
identify him--gotta scribble that name on the white board--would give the 
command to type out a file to the screen.  He either got a mess of 
published material from decade-old anarchist newsletters, some of which 
they carefully photographed on the screen, or computer-generated random 
bytes (which, of course, they thought was encrypted material).  One or 
the other of the technoids not sitting at the screen kept themselves 
shielding the power switch and plug.  Stel was sitting on the grubby 
couch waiting for the technoids to either break into the system or screw 
up.  Lenny went over and joined her, feeling miserable about the agents 
getting in through _his_ system and unwilling to watch any more and give 
away by body language when they were about to trip.  He glanced at his 
watch.  The damn cron program should ask for the password in another 20 
minutes.  "Jeez," he thought, "I hope they don't get anything."  

     "There are _10_ copies of something which looks like a word processor 
on the server hard drive--they all have the same byte count and date, and 
there is _NO_ 'path' set," technoid #3 bitched loudly enough for Lenny to 
hear.  (Happened that this was an accident.   Lenny had found that if he 
copied the word processor into each directory he made, it worked fine.)  
The server had an old 700 Mbyte drive, and a few copies more or less of a half 
Meg program made no big difference.  However at the moment, the technoids 
had concluded that this was a clever hack, that the system would wipe the 
password out of memory if they tried to run the wrong word processor 
program.  They outfoxed themselves: any one of them would have worked 
fine.  ("Type" or "copy" to the screen wouldn't work because the WD*11.0 
stored files in compressed binary.) 

     "Well, Bob, it is moment of truth time.  We can take a 1 in 10 
chance of starting up the word processor and looking at the files, or we 
can try to load in a program to extract the key from this thing's 
stinking memory.  What say?" 

     "You guys are the experts, don't ask me." 

     After a short conference, technoid #3 fished a diskette out of his 
pocket, kissed it for luck, and stuck it in the drive on Lenny's machine. 

    "Here goes nothing." and he typed "dir a:".  The crypt program was 
watching for diskette access, and came back with: 

                  "I NEED A PASSWORD! 

     "Shit."  whispered a dejected technoid under his breath.  "Know 
anybody at NSA?" 

---------------- 
   
     Lenny put the back of his palmtop on the microphone of a payphone 
and hit the dial button. 

     "That will be one dollar for the first minute." 

     Bong, bong, bong, bong. 

     "Thank you for using ESJI, you have one minute."  Buzz-click, 

     "Hello, there is no one here at the moment, but you can record a 
message."

     "Here" was a little module of code in an automated PBX/voice mail 
machine watching for incoming calls after working hours on a line deep in 
the list of numbers assigned to a small corporation.  It was an old 
machine, and unlikely to get another software upgrade.  After taking a 
call, it would not take another for several hours, and it rotated through 
several recorded messages.

     Lenny hit the next button down on the palmtop.

     #-Beep, 4-Beep, 3-Beep, 6-Beep.

     "confirm with password.
  
     L-beep, E-beep, N-beep.

     "Record message.  End with any key."
 
     Beeeeep. 

     "Nancy, its Murray, just called to say hi.  Get back to me sometime 
when you get a chance."  #-beep. 

    "Message confirmation number 36, repeat 36," and a click.
         
     The PBX made a local call to a paging company and transmitted what 
looked like a phone number.  The phone number digits added up to 36.

     Lenny punched 36 into his palmtop and hit the enter key.  It came up 
with an address, a description, and a phone number.  It was the phone  
next to the K-mart entrance about a mile away. 

    "K-mart will be closing about the time I get over there," he thought. 
"Could have taken the bike."  He closed the palmtop.  It sensed the 
closing and erased its encryption password. 

     Lenny got back in his tiny 5 year old "B-car," the 60 mpg car some 
rich dude had been force to take in a package deal when he bought a 20 
mpg Lincoln Towncar.  He twisted the key.  The lights dimmed as the 
catalytic convertor came back up to heat on the battery.  There was a few 
seconds' wait to let the battery recover, and the car started.  Lenny 
watched for cops as he drove over to the K-mart, but he didn't drive 
*too* cautiously.  That was one sure way to attract attention.  There 
wasn't much of a mob leaving the closing K-mart on a weekday.  Lenny 
parked near the phones and walked over.  He was about 20 feet away when 
the one on the left rang.  He picked it up and said, 

     "36."

     "What's the problem?  If you forgot your key, I can't help." 

     The voice on the other end sounded odd.  It was probably going 
through some blind location in Mexico where the automatic number 
identification had not yet been installed.  It also had the quality of 
digital speech.  Original words of the speaker were being converted to 
phonemes and back to words.  Not a hint of the speaker's real voice 
quality came through, though this dodge did not affect word choice and 
rhythm patterns. 

     "Agents," Lenny said.  The CCAs came in early this afternoon.  I 
don't think they got anything, but I needed someone to talk to." 

     "Dumb idea if they are watching you, but tell me what happened 
anyway." 

     Lenny related the events of the afternoon up to the point where the 
agents lost the password on his machine by trying to load a memory dump 
program from a diskette.  And then he went on. 

     "After that, they popped the cover off the server, hooked up their 
gear and copied the 700 Meg disk, a few dozen 60Mbyte SMs, and a few 
dozen 3 meg floppies.  One of them had your crypt package.  They didn't 
mention my palmtop, and Marge keeps the backup tapes at home.  Only 
took them about 2 hours. They put the covers back on and left me with 
what they called a PK encrypted 2.4 Gig WORM cartridge.  They took one 
just like it, and even made me choose which one I got.  The order said I 
was required to take one of them.  It has all kinds of legal seals and 
signatures on it.  They said take it to our lawyer.  One of us took it 
over about 5 pm.  None of us have a way to read it.  Are we in trouble?"  

     There was quite a delay.  Then, the digital voice spoke up. 

     "Even if they were able to track me down, *I* am not in trouble. I 
make a point of posting all the programs I ever give out.  In source code 
yet." 

     "I don't think you are in trouble from what they took with them.  
The copy they left with you is the data off your disk, encrypted with a 
half-key the judge issued.  Until the hearing they can't read it because 
they lack the other half of the key. The only use for it is to keep them 
from making a copy of data, changing the data and making another one of 
those write-once cartridges.  So, you are ok till the hearing."  

     There was more delay, then the funny sounding voice on the other end 
of the line went on. 

     "Presuming the passwords are not compromised, even getting the other 
half of the key from the judge to look at what they took should not be a 
big problem.  But since they came in at all, I would say you are in big 
time trouble.  That was a piece of dumb luck that they didn't try WD* on 
your files.  Of course they always have the option to give you blanket 
immunity and force the key out of you, but by the time they get around to 
doing that, you can forget the key.  I sure would.  I presume you had the 
machine convert all the files after they came in to a new password?" 

     "Not yet.  I haven't let anyone put a password into any of the 
machines since they showed up.  I'm afraid they will have a camera bug 
looking over my shoulder.  About a month ago, I read in the paper that 
they did that to a bookie in St Paul." 

     "Not likely for you--but possible.  Hmmm, did they leave any 
judicial orders about not moving the machines?" 

     "Not from what I read on the court order.  I can ask our lawyer.  
Our lawyer may be good at filing objections to logging company projects, 
but I think he is out of his depth if they go after us criminally.  I 
can't afford a criminal lawyer.  I called around and the best deal I 
could get was $100k retainer, cash or gold, no checks." 

    "They have already gone after you criminally.  You don't get a data 
search order from a judge without a fairly good reason.  On the other 
hand, it was not a search warrant.  It is arguable that they shouldn't 
have gone looking at stuff in your files, but who needs to argue?  They 
either don't have enough on you for that or they are waiting to see what 
you do and who you talk to after the DSO.  I don't know and don't want to 
know what you are doing, but there must have been something that tipped 
them off." 

     "I can't think of anything--even if the people we are sending email 
to on the east coast had all been turned, I can't see how they could have 
traced it back to us.  Mail to them was going through about 10 blind 
links, sometimes took 3-4 days to get cross country, it was deep 'crypted 
all the way, and somebody donated the digital stamps." 

     "Never like to use digital stamps I haven't bought myself with cash, 
and then only from a reputable Swiss bank.  But I can't see how that 
would have done any harm . . . . is there any chance the stamps might 
have been 'used?'  That would certainly compromise your traffic, though 
not the messages." 

     "Nope, a few of the messages circulate back to us.  They wouldn't if 
the "stamps" were no good."  

     "Not necessarily true.  The mom and pop forwarders often accumulate 
stamps for a week or more before sending them to the bank.  You just 
can't check with a bank on dollar or sub-dollar amounts--connect time 
eats you up. 

     "The first link was Telesis, and I know they are on line to the bank 
that issued the stamps . . . .  Unless they are . . . . in on it. . . ." 
Lenny was looking right at the Telesis logo on the phone. 

     "Yeah, '/Paranoia strikes deep/' . . . .  Did the court order say 
anything about why they were going after you?" 

     "No, there was a note on the order that the supporting affidavits 
were sealed." 

     "You guys rate!  There hasn't been a sealed affidavit for a DSO I 
know about in the last ten years.  The stink around the Steve Jackson 
warrant took years to wear off!  Well, they have to unseal them before 
the hearing.  The hearing has to be within the next three weeks if I 
remember right." 

     "You do, it's on the 9th of next month, 20 days from now." 

     "Well, the first thing you should do is change the password, so you 
can start forgetting the old one.  How much clear stuff was on the disk? 

     "None that I know about . . . . well actually about half the disk 
was filled with the nastiest old published stuff we could find--rabid 
libertarian literature and anarchist newsletters, public domain stuff off 
a CD ROM. The rest was filled with random numbers from a noise card when 
your guy set it up last year, then we deleted about half of it to give us 
working space.  But far as I know, there was nothing to worry about in 
the clear.  Snooper hasn't been complaining about unencrypted files when 
I run it on startup every morning." 

     "There is a hole in that program, but it takes some very special 
circumstances for it to fail.  I kind of doubt you are being watched.  If 
they were going to go to that much trouble, a search warrant instead of a 
digital search order would have been the way to go, but if you are really 
worried about them looking over your shoulder, take your machine and the 
server to a random motel you've never been to before.  Lets see, if you 
had to do the whole disk, it would take maybe two hours.  You shouldn't 
lose anything if you have to interrupt the process in the middle--wait, 
yours is a 3 person office?" 

     "Yes." 

     "Main password, and then one for each of you?" 

     "Yes." 

     "Option 4:7 is what you want to use.  It will decrypt only through 
the old main password, and reencrypt through the new password.  Data 
never comes up to clear.  Try that." 

     "Ok.  Should I take it off to a motel?" 

     "Suit yourself.  You know how good or bad you have been.  But do 
keep me informed.  Hasn't been a case this interesting in years.  Random 
route Email by preference, but call if you need to, same method." 

   ------------- 

     Lenny and Marge checked into a motel which had definitely seen 
better times, but was happy to take cash.  A lot of people had quit using 
credit cards, especially for checking into a motel on the hourly plan.  
It was just too easy for people to tap into credit card records.  The 
swimming pool was dry in July, but what the heck, they weren't here for 
swimming. 

     "I can't believe this, Marge, this power outlet has only _two_ 
holes." 

     "Lenny, this place was built before they invented grounding plugs, 
what do you expect." 

     "Well, what the heck are we going to do now?" 

     "First we look around.  No problem, the socket in the bathroom is a 
3 pronger." 

     Lenny plugged in the powerstrip while Marge plugged the pieces of 
the PCs together and connected a short network cable between them.  Lenny 
joked to keep down his nervousness; 

     "Wonder what they thought of us."  Not many couples bring in couple 
of PCs to do perverted things in the dark." 

     "Lenny!" Marge said sharply. 

     "No, Marge, I meant the _PCs_ will be doing things in the dark, not 
us."  Marge picked up on the joke by looking disappointed. She really 
wasn't.  Lenny was one of those rare guys who just did not care about sex 
with anybody.  Her regular boyfriends knew she was not getting any at 
work. 

-------------- 

     The 'crypt program rejected the first three passwords Lenny tried as 
too simple.  Which to him meant easy to remember.  He finally got it to 
accept anhtre spelled a@n7t%h7e$r (the password program would drop the 
final r).  Lenny's first password had been sesame.  He had used 
variations on opendoor, opendore, openwindow, enterhere, portculius, 
drawbridge, safedoor, gateway at various times.  If anybody had a list of 
his passwords, they would be a long way up on selecting attacks.  He felt 
he was doing the best he could to make them complex, but still 
rememberable.  He left the duress password (bugout) alone.  It was one he 
had kept using for years, and never had needed.  Lenny wasn't certain he 
would use it if he got a chance.  Even though Marge backed up the disk 
every week, he would lose a lot of work if he used the duress password 
and wiped the disk. 

----------- 
   
     They crammed the computers back into the tiny car five hours later.   
Marge dropped the key in the slot by the office and they drove back to 
the GreenRage office where Marge and Lenny set up the machines and Marge 
started the backup program.  The CCA observer made voice and printed 
notes of their return on his palmtop from the stakeout location inside a 
furniture company office about a block down the street. 

--------- 

     The office never got up to full productivity over the next five 
weeks, but Lenny did finish and email the project--with notes to the 
effect that the enclosed was chapters from a book he was writing, and a 
true-to-life description of the data search order being carried out.  He 
left it up to the folks on the other end.  If they wanted to carry out a 
project which was in the hands of the cops, it was on their heads. 

---------- 

     The DSO hearing went about as expected.  The judge granted a two 
week extension over the protest of Bruce, the GreenRage's lawyer.  When 
the day came, Lenny, Marge, Stel, and Bruce were all looking more 
respectable than they usually did.  Even Stel was wearing a dress (long 
out of style, but the only decent one she owned).  

     The hearing at the federal building started in open court with a 
request from the US Attorney for the judge to review the CCS's material 
in camera.  

     "Mr. Mulronny, I have already looked over the affidavits you sent 
over, and I can't do it.  I already granted you an extra two weeks, and 
the law can only be stretched so far.  You either have to make a case and 
let these people defend their data, or you have to drop it." 

     Mulronny looked unhappy, but was prepared with the unsealed 
affidavits.  He gave one to Lenny, one to Bruce, and one to the judge.  
The judge looked at Bruce, 

     "Your honor, this is only about 11 pages, I think my client and I 
can review it during a short recess, or you could take up other actions 
while we review this." 

     Court matters were running a little ahead of schedule that morning, 
so the judge had the clerk pencil them in after the next two short 
actions.  They went out in the hall, not worrying about snoops except 
being overheard.  The last time a judge found out that someone was 
bugging the courthouse, the head of the agency that did it spent time in 
the drunk tank for contempt. 

     Lenny had read the affidavit almost through when they reached the 
far end of the hall.  Bruce waited till he finished, and said,  

     "Well?" 

     Lenny shook his head, 

     "They're after someone else.  I've read about some of the events 
they are citing, but I sure don't know anything about them." 
  
     That wasn`t entirely true.  One of the "events" was one Lenny had 
put together, but when it didn't come off within a year, he had decided 
they had chickened out.  Since the project he had put together took out 
much of an oil refinery, he was not surprised.  Industrial sabotage on 
that scale took more than a little guts.  When the plant finally blew up, 
Lenny watched the papers for weeks, but never found out if it was ruled 
accidental.  The feds did not seem to be sure either, they only mentioned 
it as a possibility.  The other accusations were split between cases 
where Lenny strongly suspected sister organization had done the deed, or 
industrial accidents where some organization had taken credit for what 
was probably an accident. 

     Back in court Bruce complained to the judge that there was nothing 
substantial in the affidavit supporting the DSO, and that while his 
client did not have anything to hide, the government was asking to break 
into the confidential business records of a public interest group.  And 
if they would not just forget the whole thing, he wanted more time to 
respond.

     The US Attorney would have asked for more time to respond if Bruce 
had not, so he was agreeable.  The clerk set a date for 6 weeks off.
                                                  
--------

     Lenny was paralyzed from the neck down.  The judge was asking him 
for the password, and he could not remember it.  The bailiff, clerk, 
Bruce and Mulroony were all talking in a huddle and he could not make 
sense out of anything they said, no matter how hard he tried.  

    "This will do it!" one of them said, and jammed a furry dead fish 
under his nose. 

    Lenny found he could move as he pushed it away.  He woke up to find 
the cat had been licking his face and smelling of fish flavored cat food. 
                                
    5:14 AM.  "There isn't much point in trying to get back to sleep," he 
thought but Lenny flopped back on the bed.  The cat started to purr and 
kneed the covers.  Lenny absently rubbed its head, and thought about the 
next fundraising letter.  The DSO had had the effect of galvanizing the 
GreenRage membership, so donations were way up, and for the first time in 
several years, there was more than just a little money in the bank 
account of GreenRage.  Of course, it was flowing out almost as fast.  
Even though Bruce charged about half the going lawyer rate to public 
interest organiztions, fighting the DSO was going to cost them a bundle.  
"Just how much of the stuff on the disk is going to cause trouble,"  
Lenny realized he had spoken outloud.  If they asked for a special 
master, the membership list could be declared off limits.  Unlike the old 
days, when the cops could look through outgoing mail at the post office, 
an electronic mail list was fairly secure.  

     There wasn't much of interest in the finantial records either.  Oh, 
a few thousands spent for sabatage material would be hard to account for 
if they really dug into it, but the bulk of the money was spent on 
saleries, office supplies, rent, and telecom charges.  They could always 
claim the money was spent on spray cans and ceramic spikes for trees.  
And we can say we spent it for dope.  Lenny grinned at this one.  He had 
given up smoking dope, made him too paranoid.  But, every fall some 
unknown but appreciated benifactor sent the office a plastic tub of the 
stickyest buds you could imagine. Perhaps one of their above ground 
efforts had saved some trees screening the "crop."   Marge and Stel had 
split the tub the last two years. 

   The problem was not the lastest project.  Nor was it the one or two a 
month Lenny had put together over the last 3 years.  They were long 
perged, and the disk space overwritten.  And he didn't worry about the 
contents of the newletters.  Presumably *somebody* on the list was a 
ringer, and the cops had a collection of *The GreenFlag.*  What woke 
Lenny up in the middle of the night (besides his cat) was the stuff which 
they had on that WORM disk which *had not yet happened*.  He could 
probably get away with claiming that the files on the events which had 
happened were interactive fiction based on news stories.  Or could he?  
Nope, the damn files are dated prior to the "events," he thought.  And, 
even though fewer than half of the projects he had worked on ever came 
off, there were at least three or four of them they could nail me on.  

   Lenny turned the light on and pulled his palmtop out of the charging 
stand next to the bed.  He stretched the keyboard out to full size and 
set there trying to put his thoughts in order.  After entering his 
password, he brought up an organizer program.  It prompted:  State the 
problem. 

    "I don't want to go to jail for conspiricy.  The only way to stay out 
of jail is to keep the cops from looking through the GreenRage computer 
files.  Or is it?   If they can't convence the judge that they need to 
look through the files, then no problem.  If they can, then they come 
asking me for the password.  Assuming they can't crack the encryption-- 
which seems likely.  If I give it, I go to jail, if I don't, I may get 
jailed for contempt, unless they give me blanket immunity.  In either 
case, my days of managing monkey wrench projects are over." 

    The organizer program came up with: 

    You have used one or more legal terms.  We recommend you submit your 
completed outline to a lawyer. 

    It then proceeded to break the statements into an if-then-else logic 
tree which did not help Lenny much either. 

  




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Thu, 15 Oct 92 02:10:13 PDT
To: cypherpunks@toad.com
Subject: re: Game items...
Message-ID: <2962.2ADD350B@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Screw this fake scenario shit, here's some real ones:

-- Safe sex in the age of AIDS. Guess what -- oral sex is safe. Cum in
your mouth and stomach does not transmit HIV. *No one* is tracking
healthy people. There were *two* "documented" cases (none of the above
type) that seemed to be oral transmission of AIDS. Saying "oral sex is
generally safe" would amount to condoning oral sex. Fat chance in the
US.

-- HIV is not always involved in AIDS.

-- Not all people with AIDS die on schedule like the CDC says. AZT
kills people. Many people live years and years. Some few haven't died
since the "discovery" of AIDS in 85/86. No one is studying them
either.

-- Access to genuine information on RU-48 (?) the so-called abortion
pill. Turns out it does some cool stuff re: breast cancer and even
morning-after abortion.

-- Access to sexuality information of all or any kinds. Not all people
do the ole missionary position. Erotica of all kinds.


If any of these things got a reaction out of you, then maybe they'd
make good examples for privacy/encryption scenarios.


 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Thu, 15 Oct 92 03:12:15 PDT
To: cypherpunks@toad.com
Subject: re: Re: Mr. Squirrel
Message-ID: <2963.2ADD42BF@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> > Who uses ethernet?!  :-)
 U> 
 U> Everyone here at UC Berkeley.

Well, yes, but my point was really that we don't have one problem with
a single solution. What's a gaping hole in one system (physical
access) is a big HUH? in another.

 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Thu, 15 Oct 92 02:23:21 PDT
To: gnu@toad.com
Subject: Re: one time pads
Message-ID: <199210150922.AA09387@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Re. your point about security and burglary.  An intruder could copy a
one-time pad, but of course an intruder can also copy the private key to an
RSA system as well.  I'll admit that physical key control is easier with
public key systems: one just keeps one's key disc in one's personal
possession at all times, and keeps a couple of backup copies in the hands of
close trusted friends or family who understand and will take equal
precautions.  One could also design physical storage media which are
intrusion resistant in the sense of self-destructing if tampered with or fed
the wrong password; these would work as well for OTP keys as for RSA keys.

In some conceivable applications, physical security can be insured as a
matter of the vital interests of the participants.  

Again, I'm by no means trying to suggest that OTPs be considered for
particularly wide application.  Rather, that OTPs and a range of other
systems be designed, implemented, and made available so that potential users
can make their own informed choices.
-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Thu, 15 Oct 92 17:08:10 PDT
To: "George A. Gleason" <gg@well.sf.ca.us>
Subject: Re: one time pads
In-Reply-To: <199210150922.AA09387@well.sf.ca.us>
Message-ID: <9210160007.AA18430@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Physical security is not a big issue for RSA (in the pgp implementation)
because the secret key ring is itself encrypted.  The problem is not so much
physical-intrusion-to-get-the-key as it is physical intrusion aimed at
modifying software.  It would be easy to modify pgp so that the keys are
logged, etc, in a way transparent to the user.  This is why it is important
to keep both the keys and the software that manipulates them off line.  It
is also important to keep the software from being tampered with.  The best
way to do this is to put the keys and the software on a hard disk, and put
the hard disk in a computer, and carry the computer with you whereever you
go.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Thu, 15 Oct 92 17:23:16 PDT
To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings)
Subject: Re: Game items...
In-Reply-To: <2962.2ADD350B@fidogate.FIDONET.ORG>
Message-ID: <9210160013.AA19109@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>-- Access to genuine information on RU-48 (?) the so-called abortion
>pill. Turns out it does some cool stuff re: breast cancer and even
>morning-after abortion.

RU 486 (no, it's not Intel's pharmaceuticals division).

This is actually a really good example of something that could be the
subject of the game.  Medical researchers need it because it has the
potential to save lives.  However, synthesis and import of it into the
United States is banned, no matter what quantities are needed or what use it
is needed for.  It is an interesting and powerful substance and we should be
doing research on it, but instead we are letting a small minority of people
with no medical knowledge dictate the policy of our entire nation.  Oh
well.  I hope to have European citizenship someday (especially if Geroge
wins).

e





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Thu, 15 Oct 92 18:03:41 PDT
To: cypherpunks@toad.com
Subject: Re: one time pads
In-Reply-To: <9210160007.AA18430@soda.berkeley.edu>
Message-ID: <9210160103.AA06271@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



>
>Physical security is not a big issue for RSA (in the pgp implementation)
>because the secret key ring is itself encrypted.  The problem is not so much
>physical-intrusion-to-get-the-key as it is physical intrusion aimed at
>modifying software.

To add my two cents, I once had some sensitive files solen from me.
the cracker had modified the crypt command to record passwords
and current directory (since crypt only works on stdin and stdout).

In a matter of a few days they have my crypt password and enough infomation
from my file to raise some real hell.  

Note that they did not bother with breaking the crypt or guessing the password
they just rigged the system binaries.

		-Pete

PS: this happend a year ago, and last  month a copy of the files
    appeared on some systems owned by the Bay Area Air Quality Management
    District in SF (baaqmd).

PPS: I *know* that crypt is insecure but I had tared/compressed it and des
	was not avalible on the systems I was working on.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Thu, 15 Oct 92 18:13:10 PDT
To: cypherpunks@toad.com
Subject: Who uses ethernet (Mr Squirrel?)
In-Reply-To: <9210141810.AA14191@soda.berkeley.edu>
Message-ID: <9210160112.AA06320@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



>
>Who uses ethernet?!  :-)
> 

I do at home, want to tap it? simple. just crawl  under my house and
pug in to any jack, don't owrry about bringing batteies there are plenty
of 120V outlets.

		-Pete

PS: and soon I plan on using ISDN to bridge by home ethernet backbone
    onto the internet




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Thu, 15 Oct 92 18:20:15 PDT
To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings)
Subject: Re: Game items...
In-Reply-To: <2962.2ADD350B@fidogate.FIDONET.ORG>
Message-ID: <9210160119.AA06370@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



Tom, you did not sign the document with you pgp key, how am
I supposted to know that Eric did not edit this in hopes of
me having oral sex with my girlfriend?  how can I trust this is the
real Tom.Jennings and the NutraSweet version?!?

>
>Screw this fake scenario shit, here's some real ones:
>
>-- Safe sex in the age of AIDS. Guess what -- oral sex is safe. Cum in
>your mouth and stomach does not transmit HIV. *No one* is tracking
>healthy people. There were *two* "documented" cases (none of the above
>type) that seemed to be oral transmission of AIDS. Saying "oral sex is
>generally safe" would amount to condoning oral sex. Fat chance in the
>US.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 16 Oct 92 02:28:15 PDT
To: shipley@tfs.COM
Subject: Re:  Who uses ethernet (Mr Squirrel?)
Message-ID: <199210160927.AA11421@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Tom, if you're interested in ISDN, my organisation (Integrated Signal) will
probably be in a position to hook you up early next year.  We're 90% certain
to be putting in a network very close to your neighborhood.  
-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Fen Labalme" <fen@genmagic.com>
Date: Fri, 16 Oct 92 13:38:20 PDT
To: "Cypher Punks" <cypherpunks@toad.com>
Subject: Re: re- Game items...
Message-ID: <9210162038.AA10880@relay1.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


Subject:  RE>re: Game items...


>> -- Safe sex in the age of AIDS. Guess what -- oral sex is safe.
>> Cum in your mouth and stomach does not transmit HIV.

Just don't have eaten chips or have flossed your teeth beforehand.
HIV is transmitted semen to blood or blood to blood.

>> -- Access to sexuality information of all or any kinds. Not all
>> people do the ole missionary position. Erotica of all kinds.

I can't resist plugging the San Francisco Sex Information hotline.
Call 415/621-7300 with your questions of how to find it, do it better,
find someone (animal?  thing?) with which to do it with, etc....
They give good phone.

Enjoy!
Fen





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Fri, 16 Oct 92 11:47:34 PDT
To: cypherpunks@toad.com
Subject: Re: Who uses ethernet (Mr Squirrel?)
In-Reply-To: <9210161803.AA15862@newsu.shearson.com>
Message-ID: <9210161846.AA08767@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain


>
>Old hat -- I still remember the days of yore (only about five years
>ago, but it seems like an eternity) when I worked at bellcore and
>Phil Karn revealed to me that his home network was on the internet.
>All I've got from home is a wimpy little UUCP link to this very day.

What I was pointing out was how trivial it would be to compromise
such networks (not that I have such a network).




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 16 Oct 92 11:34:23 PDT
To: shipley@tfs.com
Subject: Who uses ethernet (Mr Squirrel?)
In-Reply-To: <9210160112.AA06320@edev0.TFS>
Message-ID: <9210161803.AA15862@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Peter Shipley <shipley@tfs.com>

>>
>>Who uses ethernet?!  :-)
>> 

>I do at home, want to tap it? simple. just crawl  under my house and
>pug in to any jack, don't owrry about bringing batteies there are plenty
>of 120V outlets.

>		-Pete

>PS: and soon I plan on using ISDN to bridge by home ethernet backbone
>    onto the internet

Old hat -- I still remember the days of yore (only about five years
ago, but it seems like an eternity) when I worked at bellcore and
Phil Karn revealed to me that his home network was on the internet.
All I've got from home is a wimpy little UUCP link to this very day.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Arthur Abraham <a2@well.sf.ca.us>
Date: Fri, 16 Oct 92 18:04:53 PDT
To: hh@soda.berkeley.edu
Subject: Re: Game items...
Message-ID: <199210170104.AA06520@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


re RU-486: has recently been proven to make a nifty "morning-after" pill (is
this abortion? only if you believe in the sanctity of blastula) and a study
in (I believe) S. CA. is beginning on effectiveness in brain tumors... seems
as if this drug has possible wide theropeutic (aw, who can spell?) uses
beyond directly sex-lined situations.  And RU-P5 is due out 2Q93.
-a2.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Arthur Abraham <a2@well.sf.ca.us>
Date: Fri, 16 Oct 92 18:46:46 PDT
To: hh@soda.berkeley.edu
Subject: Re: Game items...
Message-ID: <199210170146.AA14728@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


             Abortion Pill's Potential Use on Tumors
             Adds to Debate Over U.S. Market Entree
             ----
             By Ron Winslow
             Staff Reporter of The Wall Street Journal
DD        10/12/92
SO        WALL STREET JOURNAL (J), PAGE B8
LP           LOS ANGELES -- Medical researchers are studying a potential new
       *  use for the controversial French abortion pill RU-486: treatment
of
       *  benign brain tumors.
             A large-scale clinical trial was launched at the University of
       *  Southern California last week to determine whether the drug
          effectively slows or halts growth of meningiomas, tumors that
occur
       *  on the surface of the brain and spinal cord.
TX           The answer won't be known for several years, but the study adds
          another dimension to the debate over whether the drug, known as
          mifepristone, should be allowed on the market in the U.S.
          Rousell-Uclaf, its manufacturer, hasn't sought marketing approval
in
          the U.S. because of the heat of the political battle over
abortion.
          The study raises the possibility that a drug that could benefit
some
          patients won't become available because of a political dispute
over
          another application.
             "There is a good chance there will be legitimate uses for this
          drug outside of contraception and abortion," said Steven Grunberg,
          an oncologist at the USC School of Medicine. "Whether U.S.
          regulatory officials feel this will be sufficient for licensing
will
          be up to them."
             A study published last week found the drug to be effective as a
          contraceptive when taken shortly after sexual intercourse. It is
          already used in France, the United Kingdom and Sweden to induce
          abortions within the first nine weeks of pregancy.
             Meningiomas account for 15% to 18% of all tumors in the central
          nervous system, and while they are benign -- meaning that they
don't
          spread to other parts of the body -- their growth can lead to such
          problems as seizures, blindness or paralysis. Most can be removed
by
       *  surgery, but some grow so close to crucial brain structures that
          surgery isn't possible.
             Dr. Grunberg told reporters at a science writers' conference
          sponsored by the American Medical Association that the large-scale
       *  trial of RU-486 for the tumors comes after a small pilot study of
28
          patients turned up encouraging, though not definitive results.
             In the small study, eight patients experienced improvement in
       *  symptoms or had minor reduction in tumor size, according to brain
          scans. In a few other patients, growth of the tumor stabilized
after
          treatment began. While not overwhelming evidence of effectiveness,
          the results were nevertheless sufficient to persuade the Food and
          Drug Administration to approve a large study that will involve 200
          patients at several U.S. medical centers, and will be based at
USC,
          Dr. Grunberg said.
             Results from the trial aren't expected for at least four years,
          and based on current medical practice, only a small number of
people
       *  would probably benefit from use of RU-486 in meningiomas. The
study
          might have broader impact by drawing attention to other potential
          benefits of a drug that isn't available in the U.S. because its
          primary application is to induce abortion.
             Dr. Grunberg said the drug is also being studied as a treatment
          for breast cancer, endometriosis and a disorder called Cushing's
          disease, which is characterized by obesity and hypertension.
Several
          other trials have been approved by the FDA, he added, though none
          has progressed as far as the meningioma study.
       *     He said his research team came upon RU-486 as a candidate for
          treating meningiomas because the drug blocks the action of
          progesterone, a hormone that appears to promote growth of the
          tumors. "We didn't set out to make a political statement for
       *  RU-486," he said. "It just appeared to fill the bill for what
we're
          trying to do."

********************************************************************
snarf

-a2.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wixer!pacoid@cs.utexas.edu (Paco Xander Nathan)
Date: Fri, 16 Oct 92 22:31:21 PDT
To: cypherpunks@toad.com
Subject: game items
Message-ID: <9210170316.AA05655@wixer>
MIME-Version: 1.0
Content-Type: text/plain


For that matter, vibrators are illegal now for sale in Texas.  Most all sex toys have to be renamed as "personal enhancement devices" or sumsuch in retail outlets to avoid seizure.

Also, drug testing decoy materials - like powdered fake urine - are illegal in TX.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnordbox!loydb@cs.utexas.edu (Loyd Blankenship)
Date: Sat, 17 Oct 92 07:16:32 PDT
To: cypherpunks@toad.com
Subject: Intro & Keystone
Message-ID: <9210170556.AA009js@fnordbox.UUCP>
MIME-Version: 1.0
Content-Type: text/plain


First, as a newcomer, and introduction. My name is Loyd Blankenship. I am
the Product Development Manager at Steve Jackson Games, and was the
employee raided by the Secret Service that set off the formation of the
EFF, our lawsuit against them, and much angst within the government. I also
use the nome de' plume "The Mentor" when traversing the computer underground.

On to stuff relevant to the list:

A group of us here in Austin have spent a great deal of time discussing
the advantages of RSA-encrypted e-mail. I'm putting a BBS back up later
in the year, and would like to offer secure communications to my users.
Since the threat of seizure is very real (the feds still have over $10,000
(1989 street price) of computer equipment of mine since I'm "still under
investigation"), this needs to be implemented before the message is ever
written to hard disk.

To implement this, I'm currently trying to get PGP up on my Amiga, then
write the necessary C & AREXX functions to link it in with my BBS's (DLG
Pro) email function.

The outgrowth of this was the Keystone project. We're going to attempt to
get everyone in Austin cyberspace public-key capable, and get a master
keyring that will be regularly distributed via a trusted system to other
nodes in town. Ideally, you would be able to send RSA-encrypted email from
any bbs on any of the local nets to any other bbs -- even if all you know
is the destination address. We're going to do this by attempting to make
the bbs PGP-friendly. All the user has to do is generate a key pair.

The two potential weak links in this chain are line security and key
validation. The first is almost insurmountable -- unless the user takes the
time to d/l a complete copy of PGP and the Austin Keystone Keyring and
encrypt the mail on their home system. But if not, then they have to live
with the chance that someone is data-tapping. The second will rely on
face-to-face identification -- this is why we're making this a local effort.

It will probably be Christmas (when I have a 3-week vacation) before serious
strides are made in this, but I'm interested in any comments people may
have.

Loyd

p.s. What is this "game" you are talking about?

***************************************************************************
* loydb@fnordbox.UUCP	     Once you pull the pin,  *	Loyd Blankenship  *
* GEnie: SJGAMES	    Mr. Grenade is no longer *	PO Box 18957	  *
* Compu$erve: [73407,515]	 your friend!	     *	Austin, TX 78760  *
* cs.utexas.edu!dogface!fnordbox!loydb		     *	512/447-7866	  *
***************************************************************************




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sat, 17 Oct 92 13:51:21 PDT
To: cypherpunks@toad.com
Subject: one time pads
In-Reply-To: <199210150922.AA09387@well.sf.ca.us>
Message-ID: <9210172050.AA28275@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>Again, I'm by no means trying to suggest that OTPs be considered for
>particularly wide application.  Rather, that OTPs and a range of other
>systems be designed, implemented, and made available so that potential users
>can make their own informed choices.

One time pad systems are expensive enough and in uncommon enough use
that I doubt they are going to get written as free software.  I
personally am not going to work on them, because I don't want to go
buy the necessary hardware to generate and hold sufficient key
material for a practical application.

You also need hardware random number generators for a secure OTP
system.  Such boxes are not readily available, or come cheap.  While
not obvious, making random bits is a very deep problem.  See Knuth
volume 2 for some insights.

I suspect that this same argument holds for all the rest of the people
in the group as well.  I don't know of anybody who wants to implement
this system for themselves, given the cost involved.

Cryptography is all economics, and the economics here are that one
time pad systems are expensive enough that the software that gets
written for them will be for in-house use or will be commercial.  In
either case, someone is paying someone else for developing the
software.

It might be possible that there are enough people who do want this
that there is some money for development.  A perfectly possible
outcome is the creation of a consortium to hire some implementers who
would make some gnu-ware.  Such organization does not exist.  Until it
does, an off-the-shelf OTP system won't exist.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sat, 17 Oct 92 14:15:21 PDT
To: cypherpunks@toad.com
Subject: physical security
In-Reply-To: <9210160007.AA18430@soda.berkeley.edu>
Message-ID: <9210172114.AA28842@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Physical security for pgp is also necessary if you store your pass
phrase in memory.

As far as modification, detection is good enough, but you'd better
make sure your program to detect modifications is not itself
compromised!  (Does anybody detect an imminent arms race here?)

Eric Hollander is correct.  Ideally, your keys and your encryption
mechanism should be kept secure.  At some point in the future, a small
card which contains all of this will be standard equipment, as well as
a port to plug it into.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sat, 17 Oct 92 15:10:14 PDT
To: cypherpunks@toad.com
Subject: Keystone
In-Reply-To: <9210170556.AA009js@fnordbox.UUCP>
Message-ID: <9210172209.AA29900@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



First, let me congratulate Loyd and the others involved with Keystone
for working towards the creation of a local distribution mechanism for
keys.  

Every city in the U.S. needs something like this.  If it's not
happening in your area, start it.  Start by getting PGP and making your
own key.  Then exchange keys with people you know.

We have members of the list in many parts of the U.S., Canada, and
Europe.  There's plenty of work to do.  Look around.  If no one else
is doing this, you should.

>Ideally, you would be able to send RSA-encrypted email from any bbs
>on any of the local nets to any other bbs -- even if all you know is
>the destination address. We're going to do this by attempting to make
>the bbs PGP-friendly. All the user has to do is generate a key pair.

There are, roughly speaking, two kinds of privacy; one is provided,
and one is defended.  Provided privacy is unstable, since the person
using the privacy does not create it.  Defended privacy is stable,
because those who want privacy create it themselves to the level at
which they want it.  Both systems do provide privacy, no mistake.

I would be hesitant to implement a system that _only_ required a user
to generate a key pair.  This, for the users, is too much provided
privacy.  It will not teach the users how privacy really works, nor
will it give them any good idea how their privacy is being maintained.

Defended privacy does not need to be difficult.  I would spend effort,
instead of modifying BBS software, to make it easier for users to
handle encrypted email with their own terminal programs.  

Now, any privacy is better than none.  I don't really know if it is
easier to modify your BBS or your modem program.  But all other things
being equal, make it easier for users to maintain their own privacy.

>[...] a master keyring that will be regularly distributed via a
>trusted system to other nodes in town.

Again, trusted systems can turn into provided privacy.  If there is a
distributed solution you can think up, use it.

>The first [weak link, line security] is almost insurmountable --
>unless the user takes the time to d/l a complete copy of PGP and the
>Austin Keystone Keyring and encrypt the mail on their home system.

This should not be such an onerous task.  It might be now, but that
can change.  Finding ways for users to manage keys, to get keys, and
to look up keys are all interesting and useful problems to solve.

Every user should encrypt outgoing mail on the home system before it
leaves and decrypt incoming mail on the home system after it arrives.
If this is not easy, it should be made easy.

Not every user need have the complete directory on their own system.
They merely need a way to communicate with those that they want to.
This probably means a directory service, where people can download
keys for the people they want to communicate with.  Moving around a
complete directory does not scale well.

As far as BBS support, if I want to respond to someone and I don't
have the corresponding key, I should be able to initiate a zmodem
transfer of that key relatively easily, for instance without leaving
the discussion area to go to a download area.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sun, 18 Oct 92 01:21:11 PDT
To: hughes@soda.berkeley.edu
Subject: Re:  one time pads
Message-ID: <199210180820.AA24894@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Sigh... well, I guess I can see if the people I know who are interested,
would do it as a freebie...

Funny thing is, when I first looked into crypto for dissident purposes, back
in 1981 or so, I was interested in a PKS implementation, but someone else in
my circle persuaded me that OTPs would be preferable in some cases.  Now
here we are with a PKS and I'm still making noises about OTPs.  

Guess the debate is closed for the moment... congratulations, y'all, for
good arguements in a good tone.  
Now the well is about to close for the night, so I gotta scoot. 
Be back soon...

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hkhenson@cup.portal.com
Date: Mon, 19 Oct 92 02:21:17 PDT
To: cypherpunks@toad.com
Subject: one time pads.
Message-ID: <9210190136.1.13588@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


I can suggest a way to "distribute" a one time pad, even though the 
people never meet.  Just agree over the phone on which CD ROM to use,
and some forumula for an offset into the CD ROM.  You might want to
throw away some of the data to make the bit stream less regular, but
with 600 meg, who cares?  Keith Henson




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 19 Oct 92 08:48:48 PDT
To: cypherpunks@toad.com
Subject: one time pads.
In-Reply-To: <9210190136.1.13588@cup.portal.com>
Message-ID: <9210191548.AA01490@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Keith's CD-for-a-pad idea is a variant of a book code.  In a book
code, parts of the key are in various standard books, often the bible.

Advantages: easier key distribution.  

Disadvantages: key material is public.  Should an internal spy learn
the few bits of addressing information (which CD, where), the cipher
is compromised.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 19 Oct 92 17:08:26 PDT
To: hkhenson@cup.portal.com
Subject: one time pads.
In-Reply-To: <9210190136.1.13588@cup.portal.com>
Message-ID: <9210191948.AA13028@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: hkhenson@cup.portal.com

>I can suggest a way to "distribute" a one time pad, even though the 
>people never meet.  Just agree over the phone on which CD ROM to use,
>and some forumula for an offset into the CD ROM.  You might want to
>throw away some of the data to make the bit stream less regular, but
>with 600 meg, who cares?  Keith Henson

This seems equivalent to the old "dictionary" or "book" cyphers that
people sometimes used. Good cryptanalysts broke them routinely. I'll
leave it to your imagination how one might do it, but I'll just note
that if you picked a few arbitrary bytes, say bytes 30-40, of all the
CDs in the record store, you would find that those few bytes likely
distinguish all but prehaps a token number of CDs.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 19 Oct 92 17:09:14 PDT
To: hughes@soda.berkeley.edu
Subject: one time pads.
In-Reply-To: <9210191548.AA01490@soda.berkeley.edu>
Message-ID: <9210192003.AA13314@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Eric Hughes <hughes@soda.berkeley.edu>

>Keith's CD-for-a-pad idea is a variant of a book code.  In a book
>code, parts of the key are in various standard books, often the bible.

>Advantages: easier key distribution.  

>Disadvantages: key material is public.  Should an internal spy learn
>the few bits of addressing information (which CD, where), the cipher
>is compromised.

Actually, in practice internal spies were almost never needed to break
book cyphers. They in fact provide only laughable security.
Traditional ones didn't even require that the cryptanalyst ever
determine what book was being used!

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Mon, 19 Oct 92 23:22:30 PDT
To: cypherpunks@toad.com
Subject: More private PGP...?
Message-ID: <9210200622.AA10349@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


One of the things I've noticed about PGP is that it makes it pretty
obvious that you're sending an encrypted message.  The big

-----BEGIN PGP MESSAGE-----

at the start pretty much gives that away.

In most cases, this is fine, but sometimes it may not be desirable
to make it this obvious.  Sending encrypted messages may call
unwelcome attention to yourself.  Also, some people are experimenting
with packet radio on the amateur bands, and it's not legal to send
encrypted messages there.

What I think would be nice would be an "innocent" mode for PGP
in which it created files which looked like something else.  For
example, what if your encrypted output file looked like:

begin 666 testpat.gif
MI\44:#G4D>QQXR!-M,Z20O1K&5D<U"C;V<J#-I@:ANT,A+>0, 5-4F.X<%MT
M2:V94,K;XE@B?]%IHF+_<VT=U! 3Q;;M-K<QT.N"?%IJTNU!%(KF7K]2^B6+
M;&TTGTULW(4%:F@\&MB^ ^Y5Y\#2A6^*86F-Y"^%J$>WGI%(]#=F]/[LV+&!
M,NH0(!3B35CW#!-Z7"B_L'=-C 8DLB-(J R"3?EE9<.>QE4Y?T$66IA7B@W?
end

This will be recognizable, if you've seen many, as a uuencoded file,
a common encoding for non-ascii files.  The header line suggests
that it is a graphics file.  Tons of these types of files are sent
across email networks every day.  Sending your encrypted messages
in this form would give you a lower profile.

Still, if someone goes to the effort to uudecode your message,
and examines the resulting file, it will be obvious that it's not
a GIF file because it lacks the proper headers.  Instead, with
the current PGP implementation it will be obvious that it is in
fact a PGP file, because the header format matches the PGP spec.

Again, I think it would be better if PGP in this mode were able to
produce a file without headers which will give away what it is.  Even
better would be the ability to mimic headers of some other types
of files, such as the .ZIP, .ZOO, or Unix "compress" format which are
often used in binary files people mail around.

Another thing that I think is kind of bad about PGP in the context
of avoiding traffic analysis is that it puts the key ID of the
destination person in the header.  There was some discussion during
development of a mode in which no key ID information would be in the
header; the only way you'd have of knowing if the message was for
you was to try decrypting it.  (There is a checksum which is used
internally to tell if the decryption was done with the right key.)
This way you could broadcast messages to some group, and no one could
know which person in the group you were sending to.

These "anonymous destination" messages could be encoded with a key
ID of zeros, and the PGP software could easily be modified to let
the user try a decryption on such a message, reporting success or
failure.

How useful do these kinds of features seem to people?  Would they
really be helpful or is this just paranoia?

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Tue, 20 Oct 92 01:56:22 PDT
To: hkhenson@cup.portal.com
Subject: Re:  one time pads.
Message-ID: <199210200855.AA27037@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Re use fo CD ROMs for OTPs.  That would seem to be a variation on the old
theme of the book cipher, which is *not* random and therefore *not* secure.
Also, agreeing on key procedures over the *phone* in *clear voice* is kind
of like sex without a condom.  Not secure.  Not safe.  Potentially deadly.

While we're on the subject of link encryption, the same response pertains to
the suggestion made by someone from SJG here (whose name I ought to know but
my memory for names has more holes than Bush's economic plan) about key
distribution and transmission of cleartext over phone lines.  It *doesn't
matter* if it's encrypted at the BBS server, if it goes in clear over the
phone.  Keyword in context recognition is no problem when dealing with
ASCII.  Various agencies (you know who) have raised this to a fine art.  The
telephone line is precisely the link in the chain which is weakest and needs
most to be protected.  If the nasty-wasties break down your door and go for
your hard drive, it's already too late.  Like worrying about a condom after
the fact.  

Now as a matter of record, 
it's been demonstrated that a processor emits electromagnetic radiation back
over the phone lines as well as electrical power lines, which can be picked
up at a distance.  So consider for a moment that there is a BBS serving
dissidents, who Big Brother wants to monitor.  Seeing all the encrypted
traffic, they install a device on the phone line and the AC to pick up what
the mircoprocessor is doing.  And they see it doing crypto, and they see the
cleartext which is recovered, and get the keys, and the whole damn thing may
as well be transparent.  So for BBSs and such, I would argue that it's
necessary to have electromechanical relays to isolate the computer from the
phone lines when encrypting or decrypting; ideally isolate it from the AC as
well (using an uninterruptable power supply, which will run the computer on
batteries for some period of time, say 45 minutes).  So you have a great big
red toggle switch next to the computer, and for some period during the day
when doing all the crypto processing, throw the switch to the Safe position
to get it off the phones and AC lines.  This might make BBS use a little
less convenient (in that email becomes available the day after it was
posted), but at least it's not literally leaking everyone's secrets into the
airwaves.  

This general area is part of a larger topic called TEMPEST.  Anyone else
interested in pursuing this angle...?

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Tue, 20 Oct 92 02:16:09 PDT
To: nobody@soda.berkeley.edu
Subject: Re:  More private PGP...?
Message-ID: <199210200915.AA27714@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Hal, I think those would be vry useful.  Now of course, we don't want to
advocate that radio users in the United States do anything like sending
ciphertext over the airwaves, but we might want to develop something that we
can ship to the Gusanos who want to take Cuba back for the Mafia, or maybe
in a better vein, something that the Tien-an-men kids can use when
overthrowing the Commies in China.  

Good ideas about message headers.  Since the source code for PGP is widely
available, it would seem a straightforward matter to alter the program to
include the new features.  

What I'd really like also is a Mac version....

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Tue, 20 Oct 92 07:52:54 PDT
To: cypherpunks@toad.com
Subject: Tempest.
Message-ID: <9210201452.AA01970@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Re TEMPEST technology:

(Note that TEMPEST is the technology for _protection_ against electronic
eavesdropping on your computer emissions.  There is presumably a code
word for performing such snooping, but it must be secret.)

I've read that the worst emitter is your CRT screen.  In fact, they
say that you can sometimes put a TV-type monitor next to your computer
monitor and get a faint, ghosty image of your CRT screen on the second
monitor.  If you get this much without any amplification, it's under-
standable that high-quality equipment can pick up an image from a
greater distance.

The best way to avoid this, IMO, is to use a laptop.  The LCD display
of a laptop does not use the large electromagnetic fields that a CRT
display does.  Laptops also use lower power levels in general so they
should emit less.

I don't really know whether the "raw" CPU activity of your computer could
be picked up and interpreted at a distance.  With as many different
signals as there are on the address and data busses, along with all
the other wires you have, I can't really see how anything meaningful
could be picked up with remote monitoring.  It would seem that they'd
be totally jumbled.

So, for BBS use, where the system is operating automatically, I'd say
that it would be OK as long as you don't display any cleartext or
key/password information on the screen.  You could just turn the monitor
off when it's operating.  For home use, a laptop has the advantage that
it can have greater physical security (because it's smaller and more
portable), you can carry your decryption keys with you, you can download
to it at work or school and decrypt without trusting the multi-user
systems they have there, and it should be relatively immune to electro-
magnetic snooping.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 20 Oct 92 08:33:46 PDT
To: cypherpunks@toad.com
Subject: More private PGP...?
In-Reply-To: <9210200622.AA10349@soda.berkeley.edu>
Message-ID: <9210201533.AA07309@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


>One of the things I've noticed about PGP is that it makes it pretty
>obvious that you're sending an encrypted message.  [...]  Sending
>encrypted messages may call unwelcome attention to yourself.

First, let me get on record as saying that Hal's "innocent mode" is a
good idea that should be implemented.

But it's not really a good long-term solution from a social point of
view.  Encrypted traffic should become the norm, not the exception.
Flagging that you're sending encrypted traffic should be encouraged.
When questioned about this, people should respond in shocked tones
"What do mean?  Aren't you encrypting _your_ email?" and then proceed
to suppress gentle laughter at them when they say no.

When it's cool to encrypt, only the uncool will be plain.

So, then, more peer pressure!  Consider someone asking you about your
encrypted mail to be an opportunity to start a conversation about
their position on personal privacy.  When your sysadmin asks why your
mail can't be read, tell him you are defending your privacy and ask if
there is any problem with that.  Then, when the sysadmin puts in a
filter for PGP traffic, use innocent mode.

>Another thing that I think is kind of bad about PGP in the context
>of avoiding traffic analysis is that it puts the key ID of the
>destination person in the header.  

Absolutely.  Ditto for signatures.  Both should be able to be
selectively removed.  In any case, it should be possible to have
nothing appear on the outer envelope.

Another feature for PGP would be automatic message padding.  To
properly do a mix you need to quantize the message lengths.  If PGP
were to automatically pad with random data, it would save a lot of
integration work for the mix.  PGP already has a random number
generator, after all.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 20 Oct 92 09:15:10 PDT
To: cypherpunks@toad.com
Subject: Tempest.
In-Reply-To: <9210201452.AA01970@soda.berkeley.edu>
Message-ID: <9210201614.AA13762@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



About Tempest.

The ability to monitor is real; it's more powerful than you would first
imagine.

You can get a lot of insight into what is possible by looking at what
is sold as parts for Tempest certification.  There is some trade
publication devoted entirely to such matters; it's called EMI/RFI
News, or Interference Protection News, or something like that.  It's
free to qualified subscribers.  The articles are interesting, but
cannot delve into the really interesting stuff.  But the ads!  Look at
what people are selling, and remember that it is protecting against
something.  Stuff like copper impregnated gasket material, both for
computer cases and for doors (in walls).  Copper braid and cloth.
Conductive glues and caulks.  Special connectors.  Electrical
isolators.  Fiber optics.

(Aside: If you don't know how to be a qualified subscriber, you're no
hacker.  Look closely at the subscription card and then figure out
where the publisher of a free magazine gets its money.)

What is possible?  CRT monitoring.  A Dutch guy named van Eyck
demostrated six years ago or so a CRT monitoring system which he built
out of spare parts.  It consisted of an TV roof antenna, a non-detent
UHF tuner (which you can make yourself by removing the detent plate
from an old TV), and a multi-scanning monitor.  No amplification
beyond what was in the tuner, no sync stabilization, no special
directional antennas or any other tricks.  He was able to reliably
pick up monitor emissions from 100 meters, if I remember correctly.
Fancier equipment knows what your screen sync rate is, uses bandpass
filters, uses better antennas, knows to look for mostly-persistent
frame information, looks for emissions signatures, and is able to read
one CRT out of a hundred at half a mile.  I suspect this is a low
estimate of the ability of modern equipment.

Hal mentions using flat panel displays to combat emissions.  This
works, as evidenced by the continued existence of Grid Computer.
Remember Grid, who came out with these way-expensive gas plasma
laptops around 1985/6?  The reason they sold so many of those and are
still around was that a large number of them were Tempest certified.
(Even larger revenues!)  I understand that the Tempest spec Grids had
a thin layer of gold foil in front of the screen, even so.  Yes, gold
thin enough to see through.

Signal wire monitoring.  Using twisted pair or coax cable, reduces
transmitted energy down to very low levels, improving energy transfer
and reducing monitorability.  But even with zero radiated energy there
is still the near field of the wire which can be inductively tapped.
No conductive contact is necessary.  If you can put a wire next to my
phone line somewhere, you can tap my phone.  It's by nature a high
impedance tap, requring sensitive ampilifiers but at the same time
difficult to find even by a reflectometer.

Without a twisted pair, the situation is worse.  Keyboards for the PC
use a serial protocol at a fixed frequency.  The cables are not
twisted pair.  I haven't heard anything about that specifically, but I
presume that keystrokes can be read extremely easily.

CPU monitoring.  Yes, it's possible.  I've heard that it is possible
to actually run a CPU in parallel with a monitored one.  In order to
do this, you need to correlate signals in real time across a fairly
wide RF spectrum.  Each CPU pin or I/O bus signal occurs in a
different physical location inside the case.  The case is active in
terms of emmission, reflecting signals around like mad.  All these
different physical locations and reflections give rise to phase
differences and interference patterns.  Once you figure out what the
signatures of the various signals are, you can separate them out from
each other by correlation and deconvolution.  George's concern about
emissions through phone lines falls into this category.

Other stuff.  I've heard rumors about using microwave pinging to
determine stuff about electrical equipment.  Or about implanting
passive devices that alter the EM field locally in order to make
monitoring easier.  It's safe to presume that there is some amazing
stuff going on.  Read The Puzzle Palace for more hints.  (Like the
valley in WV which is one big antenna.)

Emissions monitoring is also all economics.  The price to monitor
increases with each more sophisticated attack.  CRT's are easy, CPU's
are hard.  I would like to see public research in this area, just like
there is public research in cryptography.  Until the public has a
better idea of what various attacks cost, there can't be rational
decisions about emissions security.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Tue, 20 Oct 92 11:40:12 PDT
To: nobody@soda.berkeley.edu
Subject: Re: Tempest.
In-Reply-To: <9210201452.AA01970@soda.berkeley.edu>
Message-ID: <9210201839.AA08315@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Like I said, just carry everything (keys and software) on your laptop.  As
soon as the Mac port of the pgp is finished, that's what I'll do.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnordbox!loydb@cs.utexas.edu (Loyd Blankenship)
Date: Tue, 20 Oct 92 14:43:30 PDT
To: soda.berkeley.edu!hughes@cs.utexas.edu
Subject: Re: Keystone
Message-ID: <9210201753.AA009kv@fnordbox.UUCP>
MIME-Version: 1.0
Content-Type: text/plain


:I would be hesitant to implement a system that _only_ required a user
:to generate a key pair.  This, for the users, is too much provided
:privacy.  It will not teach the users how privacy really works, nor
:will it give them any good idea how their privacy is being maintained.

I take the opposite view -- I dare *not* supply such a system. Any user that
is interested enough in 100% privacy will be encouraged -- both from the
email prompt and through the message bases/file areas -- to d/l a copy of
PGP. I'll probably write a tutorial on using it as well.

But many users do not have the interest/time/ability to set up PGP on their
home system. For them, I want to provide the best possible privacy given the
ease with which anyone who can find their local LMOS can tap (voice or data)
a line...

:Defended privacy does not need to be difficult.  I would spend effort,
:instead of modifying BBS software, to make it easier for users to
:handle encrypted email with their own terminal programs.

I don't have my user's terminal program -- I *do* have the bbs software.

:Again, trusted systems can turn into provided privacy.  If there is a
:distributed solution you can think up, use it.

I don't know any way to maintain an up-to-date, central keyring without
someone being in charge of regular updates. I'd make it available via
Fido, FTP, BMS and regular d/l.

Loyd

***************************************************************************
* loydb@fnordbox.UUCP	     Once you pull the pin,  *	Loyd Blankenship  *
* GEnie: SJGAMES	    Mr. Grenade is no longer *	PO Box 18957	  *
* Compu$erve: [73407,515]	 your friend!	     *	Austin, TX 78760  *
* cs.utexas.edu!dogface!fnordbox!loydb		     *	512/447-7866	  *
***************************************************************************




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
Date: Tue, 20 Oct 92 16:26:17 PDT
To: cypherpunks@toad.com
Subject: Depository Proposal (revised)
Message-ID: <3194.2AE470FA@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Just thought I'd forward on something that's cooking in Fidoland.
This guy has code running already. I haven't even looked at it yet
myself If it's a crock, please be kind and forward suggestions to the
author... 

			tomj@fidosw.fidonet.org






-------------------- begin forwarded message

 (Please note that examples still have not been included with this text)


                  Public Keys Depository Proposal
                        By Marcos R. Della
               (1:125/180 or marcos@zippy.sonoma.edu)


Def:  De.pos.i.to.ry (di-POZ-i-tohr-ee) n. a storehouse, a place for
safekeeping of things

-+---------------------------------------------------------------------+-

With the latest release of the PGP20 program, public key availability
has fallen into the hands of the individual.  This provides a relative
degree of security over messages that are sent from user to user in
various formats (text, binary, etc) over different transportation
mechanisms.  I will not go into the system that allows public keys to
work nor public key history.  Instead I'll point you to the rather
complete documentation that comes with the PGP program.

Unfortunately, there is a major drawback to this system (also pointed
out in the PGP documentation).  Public key distribution has few
security elements involved to insure the validity of a particular key.
PGP attempts to address this problem by providing a "signature" system
to each public key to give reasonable validity to its origin.
Unfortunately, this depends upon trust of the individual who signs the
key to begin with.  Who polices the policemen?

Unfortunatly, the issue of key validity is yet another topic that
cannot be easily addressed since authenticity lies in one persons
trust of another.  Yet there still needs to be a system in which keys
can be distributed or held for later use.  This system should be
multiply redundant and have some degree of immediate access in order
to make the information stored useful.  One such system would be a
depository, a place to store public keys for later retrieval.

This proposal will attempt to describe a system whereby you can get
around the validation of public keys problem without requiring someone
to police the Depository itself!

--------

Problems Involved:

 - How do you know the key depositor isn't faking his/her keys?

 - How do you verify (at the depository) that a key being deposited is
   from the key originator or is even valid?

 - What is to prevent the depository from faking keys that is "signs"?

 - How can this system be resonably redundant and easy to access?

First off, the depository is NOT a validation center.  The system
never will verify the users as existing or if they are even honest
users.  The depository key signature only verifies that the key has
been deposited and is available for access at any time.  Again, the
depository DOES NOT verify users, only the fact that a deposit has
been made.  (A better form of deposit slip)

If a user wants to deposit his/her key, what is to prevent the sysop
from intercepting this public key, making a substitution replacement,
and then forwarding the new public key?  Unfortunately, there are
sysops out there that have already done this in some respects.
Thereby the system has to place the responsibility upon the user for
key deposit verification.  To prevent the sysop from changing the
deposit, the user should use the Depository Public Key (hereafter
referred to as DepoKey) to send his/her key for deposit.

Again, what prevents the "bad" sysop from just throwing this message
away (obviously he can't read it) and sending a fake message (also
encrypted with the DepoKey)?  Although this eventually thwarts the
entire system (the sysop cannot fake the users public key unless the
user uploads it in plain text to the sysop), it still causes problems.
To prevent this, the user should include some sort of text in the
deposit that the depository will mail back to the user, ENCRYPTED
along with the user's public key.  When the user receives a valid
message back that contains his original text, things are fine.  If the
user does not receive a response in a few days or gets an incorrect
return message, then the user should send a cancel message to the
depository and re-deposit his or her key.  The complete the handshake,
the user should send an authentication back to the depository stating
that the key was recieved correctly (instructions on how to do this
should be returned with the key). If a return reciept isn't back in a
resonable period of time, the depository will remove the key from its
deposit keyring.  NOTE:  This will never invalidate a public key, it
will only prevent it from being distributed via the depository system.

What is to prevent the depository from faking keys that it "signs"?
Well, in order to be effective with fake keys, you need to be in the
transport path of the messages that you are planning on "stealing".
Since the depository is not a major hub or node (except possibly to a
few people) this negates any effect of faking keys.  Also, once a user
has received verification that the depository has his public key, he can
then also post it anywhere.  The depository will return his public key
with a depository signature on it.  This allows the user to upload a
verified key to anywhere.  When keys are distributed with a depository
signature on them, then they are on file with the depository in case
someone wants to withdraw them later.

As long as the public key for the depository is made worldwide public,
this system will work.

As for creating a multiply redundant system, there should be several
sites that are listed as depositories.  These systems will on a weekly
basis, exchange acknowledged keys (ie, keys that have undergone the
handshaking process) with one another.  A user can then request a key
from ANY of the depository sites and get the same information.

For those that want certified keys (other than from the users) such as a
BBS system needing the public key of another, there will be a withdrawal
mechanism built into the depository to pull single or multiple keys.
Also, the complete public keyring may optionally be pulled (FREQing).

-----------

The actual mechanism:

Below is the Depository Public Key.  Any public key that has been signed
with this depository key will be assumed to have undergone the handshake
process to verify that the originator of the key pair has in fact issued
a valid key.  This signature only verifies the deposit (a reciept).

*** THIS KEY DOES NOT VERIFY THE IDENTITY OF THE USER!!!  ONLY THAT ***
***      THE USER WAS IN FACT THE ORIGINATOR OF THE PUBLIC KEY      ***
***      AND HAS DEPOSITED IT INTO THE PUBLIC KEY DEPOSITORY!!!     ***

For user identification, there should be a second or third signature
from a BBS or known friend.  This will give the key a verification
level.  If the user wishes to deposit a key with another person's
signature, there will be no problem since the handshake method still
insures the source and destination of the message.  (Note:  This is
preferred since depository keys will then be distributed with dual
signatures)

The depository allow four functions:  Deposit, Withdrawal, Cancel, and
Acknowledgement of Deposit.  To use these function...

DEPOSIT:  Address a message to "Depository" at one of the listed
depositories at the end of this document.  The subject will be "Deposit"
and the text body will contain your Public Key (in Ascii format) and
some small body of text that will be reflected back to you.  NOTE:  The small
body of text and your public key should be encoded WITH the Depository Key.

WITHDRAWAL:  Address a message to "Depository".  The subject will be
"Withdrawal" and the text body will contain what you are looking for on
each line just as if you were polling your own PGP program.  You will be
sent back a list of keys with the depository signature verifying the
message.  Note that a * for the body text will give a LONG list back to
you...  For fidonet, this MIGHT require a poll to recieve your return list.
See Appendix A

CANCEL:  Address a message to "Depository".  The subject will be
"Cancel" and the text body will contain the text "CANCEL PUBLIC KEY"
with your signature on the message.  The cancel will not take place
without your signature!  You will receive a cleartext response to this.
All this does is to remove your public key from the depository keyring.  If
this comes with a "kill" signature for the key, then it will be moved from
the deposit keyring to the invalid/killed keyring.

ACKNOWLEDGE:  Address a message to "Depository".  The subject will be
"Acknowledge" and the text body will contain the text "ACKNOWLEDGE" with
your signature on the message.  Without the signature, your public key
will continue the daily countdown to keyring removal.  A cleartext message
will be returned upon any receipt of this message.

Anything that doesn't fit one of these will be rejected and a return
message will be bounced back.

-------------------------------------------------------------------------

                          *** WARNING ***

This proposal ONLY provides a method of storing keys for public
distribution and withdrawl.  This in NOW WAY verifies or even attempts
to verify the authenticity of the issuer of the key.

                          *** WARNING ***

----------------------------[ CUT HERE ]---------------------------------

Depository #1 (1:125/180) [KeyID:77854F] "Depository #1 [Public Keys]"

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAirV7H4AAAEEAMgk39sU7OvZGr/Ig/g0Kaw2cY3FpQOFvRXp9OXmlAch3FBA
Ow2/oD8dbKdiQamuIMFw6qpg0Bw2k8mhKXCfFhLIZjH3FJeqKQrV7UvELBJdCT4q
b7wRg8jeLos2rR9a4jt+s0srNS/LznfLvquESEhMuzcxSTC27OyxS4Fbd4VPAAUT
tBtEZXBvc2l0b3J5ICMxIFtQdWJsaWMgS2V5c10=
=rC+3
-----END PGP PUBLIC KEY BLOCK-----











--- GEcho 1.00/beta
 * Origin: The Babble Underground (Home of the Jabber QWK Reader) (1:125/180)
SEEN-BY: 125/111 125 180 185 374/14
;;
-------------------- End forwarded message

--
Tom Jennings / World Power Systems
  email:   tomj@fidosw.fidonet.org
FidoNet:   1:125/111, BBS +1-415-863-2739
 postal:   Box 77731, San Francisco CA 94107 USA

--  
tom jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: G5100035@NICKEL.LAURENTIAN.CA
Date: Tue, 20 Oct 92 10:12:23 PDT
To: cypherpunks@toad.com
Subject: Unsubscribe me from mailing list
Message-ID: <01GQ68KC14008WWO6L@NICKEL.LAURENTIAN.CA>
MIME-Version: 1.0
Content-Type: text/plain


I can no longer handle the mail volume from your mailing list.
Please unsubscribe me from the list.

Thanks.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: No_Such_Address@atdt.org
Date: Tue, 20 Oct 92 11:06:12 PDT
To: cypherpunks@toad.com
Subject: Mac Version PGP
Message-ID: <9210201806.AA07990@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


No one has been able to get me the source-code to PGP, and when
I ftp'd it from wherever, it came ZIP'd in a format that my
unzipper doesn't recognize.  (Maybe I've been ZIP superceded).
Anyway, it hasn't been very convenient to get a hold of it for me.
 
But, it should be fairly straight forward to throw it into
THINK C.  THINK C supports a console with command-line.  You
would not necessarily have to Mac-ify it (although it would
certainly make it more aesthetically pleasing); so porting
to the Mac is not a dead-end port.  THINK C should be
able to compile and execute PGP as-is.
 
As soon as I can get the source, I'll put my words into action.
 
(re: Macifying it: It's simple enough to slap together an
interface on top of something like PGP; that's one, maybe two
dialog boxes with a bunch of radio buttons and check boxes
and a routine to parse it all and hand the info over in a way
PGP expects.  BFD.  So, criticisms I've heard about
it being a hassle and a pointless exercise to port PGP to the
Mac are without merit, as far as I'm concerned.)
 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: shawnb <shawnb@ecst.csuchico.edu>
Date: Tue, 20 Oct 92 15:15:53 PDT
To: cypherpunks@toad.com
Subject: Fakemail
Message-ID: <9210202215.AA29362@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Cyperpunks....

Man you guys generate lots of stuff...
Anyhow I noticed that some of you are using fakemail...
Are you using a shell script for this? The only fakemail scripts I've seen
have not really worked.  Could someone forward a copy to me? 
Thanks.

Shawn




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 20 Oct 92 15:27:38 PDT
To: cypherpunks@toad.com
Subject: TEMPEST, Eavesdropping, and PDAs
Message-ID: <9210202226.AA28803@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Eric Hughes posted a nice summary of the TEMPEST situation
(interception of RF for eavesdropping on computers). I'll just add a
few comments.

> About Tempest.
> 
> The ability to monitor is real; it's more powerful than you would first
> imagine.

And the NSA has reportedly restricted several papers on this, though
they can't do much about the stuff coming from abroad. Their chief
concern doesn't seem to be folks like us, but rather concerns about
vans parking outside high tech and defense contractors and slurping up
what they can from non-TEMPEST (all caps, for some reason) terminals
and computers.

And someone asked about building Faraday cages. Don't even try! In
1972-3 I worked inside a Faraday cage in the lab of Dr. Paul Hansma
(who's now famous for his atomic force microscope work--small world),
and it was real tough to shield against high frequencies (above 500
MHz). Modern computers run at 50MHz and faster and the signal edges
are of course much faster. RF emissions are a major hassle, and even
30 dB of shielding will still mean enough emissions for a dedicated
listener to pick up.

> Hal mentions using flat panel displays to combat emissions.  This
> works, as evidenced by the continued existence of Grid Computer.
> Remember Grid, who came out with these way-expensive gas plasma
> laptops around 1985/6?  The reason they sold so many of those and are
> still around was that a large number of them were Tempest certified.
> (Even larger revenues!)  I understand that the Tempest spec Grids had
> a thin layer of gold foil in front of the screen, even so.  Yes, gold
> thin enough to see through.

BTW, I have one of the original magnesium-cased, bubble-memoried GRiD
Compasses. Tres elegant (and even "way cool"....Not! It heats up
something fierce, with the magnesium case acting as a heat sink). (I
got this at Weird Stuff Warehouse, complete with a magnesium-cased
disk drive, cables, etc., for $250. Fully functional, but not a lot of
software written for "GRiD-OS." Maybe I'll bring it to the next
Cypherpunks meeting.)

> monitoring easier.  It's safe to presume that there is some amazing
> stuff going on.  Read The Puzzle Palace for more hints.  (Like the
> valley in WV which is one big antenna.)

Ditto on this book recommendation: all would-be cypherpunks should
read James Bamford's "The Puzzle Palace." Though published in 1982, it
revealed a lot about such "No Such Agency," so much so that the
director of NSA, upon encountering Bamford at a dinner, refused to
shake his hand and said "Sir, I consider you an unindicted felon!"

> Emissions monitoring is also all economics.  The price to monitor
> increases with each more sophisticated attack.  CRT's are easy, CPU's
> are hard.  I would like to see public research in this area, just like
> there is public research in cryptography.  Until the public has a
> better idea of what various attacks cost, there can't be rational
> decisions about emissions security.

I think the longterm solution to this problem is the same as that for
the key problem: small, highly portable, self-contained computers for
doing the most sensitive work and for providing passwords to remote
systems. Smartcards are one approach, though they obviously are highly
constrained in what they can do other than act as ATM or VISA cards.

(Laptops are one idea. Following Eric's suggestion that we look into
TEMPEST issues, perhaps we could "rate" different laptops and PCs for
emissions. Just a thought.)

Apple's "Newton" PDA ("Personal Digital Assistant"), General Magic's
whatever (talk to Fen L., who works there, but who won't say much),
Eo's Hobbit-based PDA, and other systems (Sharp, Casio, etc.), offer a
better platform, at least for the long term. With 100 MIPS
performance, LCD screens, and no dangling keyboards and cables, these
gizmos should be favorably positioned for security-conscious
applications. RF emissions should be low to begin with (and can be
characterized, of course); additional shielding should be easier to
achieve than with full-sized units.

PDAs also are small enough that people will carry them everywhere,
thus both enhancing security against tampering, and also making them
workhorses for security applications. With a good interface to desktop
machines, the critical security functions can be done inside the PDA
(e.g., accessing a terminal or remote system using zero knowledge
protocols, where the PDA answers a challenge question without
revealing the actual password or whatever secret key). The announced
PDAs also have slots for "PCMCIA" cards, small credit-card-sized cards
that can add functionality and memory.

The lack of a keyboard in the smallest of these units will be a limit
(though external keyboards are options...and with some care, these
keyboards can even be made TEMPEST class, though leakage will still
persist. A battery-operated keyboard with fiber-optic link to the PDA
might be one approach.). 

The issue of hooking these PDAs to desktop machines and networks is an
interestesting one. Wirless links would seem to be risky, except that
if all critical computations are done _inside_ the PDA then what gets
transmitted is not really "fragile" (in the eavesdropping sense). I
suspect that someone will offer a small fiber optic link (like the one
I have going between my CD player and my DAT machine).

And it will be a couple of years before these become common. But it's
about 2-3 years from now that our mission gets really interesting,
anyway. Digital money, anonymous voting and conferences (imagine using
wireless, encrypted links in meetings to negotiate without opponents
knowing..just one of several small business product niches), and all
kind of other crypto anarchy ideas.

PGP 3.0 for PDAs!


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.












From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Tue, 20 Oct 92 16:53:46 PDT
To: cypherpunks@toad.com
Subject: another service
Message-ID: <9210202353.AA04723@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I have thought of another service, like the depository, which might be
useful to the user community:  a time stamping notary service.  This would
have less security problems than the depository and would also be neccessary
if RSA'ed documents are to replace contracts and other paper documents used
in business.

It would be easy to implement.  A machine is set up with a hardware random
number generator.  This is used to generate a time-stamp key pair, perhaps
every day or every hour.  A user sends a document to this computer, which
then signs it with the private half of the time-stamp key and then remails
it to the user.  Note that the document sent by the user is probably
already encrypted and/or signed; sending it to the time-stamper does not
compromise it in any way.

The time stamper also keeps publishing the public half of its keys, to a
wide enough audience that it would be impossible for any one person (or
Agency) to modify all of them.  Users could keep their own archives of
them.  After the time period has elapsed, the time-stamper should erase the
private key corresponding to the time period.  This is the only time that
trust is involved and that the system might be compromised.  If a private
key were leaked, a time-stamp could be forged.

This would allow users to keep dated, notarized documents in their files, so
they could later prove that they had certain information at a certain time.

Ideas?  Thoughts?

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Fen Labalme" <fen@genmagic.com>
Date: Tue, 20 Oct 92 17:45:27 PDT
To: uunet!atdt.org!No_Such_Address@uunet.UU.NET
Subject: Re: Mac Version PGP
Message-ID: <9210210045.AA28410@relay1.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


Subject:  RE>Mac Version PGP


> No one has been able to get me the source-code to PGP, and when
> I ftp'd it from wherever, it came ZIP'd in a format that my
> unzipper doesn't recognize.

There are several mac un-zip programs available for anonymous ftp from
sumex.stanford.edu (cd info-mac/util; mget unzip-11.hqx mac-zip-10.hqx). 

> But, it should be fairly straight forward to throw it into
> THINK C.

A person here has put a short amount of effort into "macifying" PGP.
He's gotten it to compile in Think and MPW, but it won't run yet.
According to him, the technical reason is that some sort of "goofy
bus-error bullshit" is occuring, and so, if you figure it out, please
let this list know (as well as possible posting it to alt.crypt.sources,
if such exists).  We will do the same.

Good luck!
Fen





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 20 Oct 92 17:15:26 PDT
To: cypherpunks@toad.com
Subject: Re: another service
In-Reply-To: <9210202353.AA04723@soda.berkeley.edu>
Message-ID: <9210210014.AA05539@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Eric Hollander writes:

> I have thought of another service, like the depository, which might be
> useful to the user community:  a time stamping notary service.  This would
> have less security problems than the depository and would also be neccessary
> if RSA'ed documents are to replace contracts and other paper documents used
> in business.

Bellcore is offering some form of this service, or plans to. Stuart
Haber, one of the codevelopers, described this at last year's Hackers
Conference and presented a paper at the Crypto '90 conference, or
possibly the Crypto '91. (I have a Xerox of the paper someplace and
may be able to dig it up if you're interested)


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Tue, 20 Oct 92 02:19:05 PDT
To: cypherpunks@toad.com
Subject: Home security...
In-Reply-To: <199210200855.AA27037@well.sf.ca.us>
Message-ID: <9210200918.AA18129@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


>This general area is part of a larger topic called TEMPEST.  Anyone else
>interested in pursuing this angle...?

What's the best sources for faraday cages and TEMPEST etc? And does anyone
out there implement anything of this type of security at home to protect
against monitoring? The cost of such an exercise would be rather prohibitive
to say the least.

Just curious..
Mark





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Wed, 21 Oct 92 01:16:08 PDT
To: mark@coombs.anu.edu.au
Subject: Re:  Home security...
Message-ID: <199210210815.AA06441@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Tempest: there are companies which make cages for Macs and PCs, I don't have
addresses but they can probably be found with some searching of ads.  The
main application it would seem, is not the individual home user (unless
s/he's a notorious digital dissident) but rather the encrypted BBS,
particularly one which decrypts and re-encrypts or retransmits messages.
Consider the labor cost of monitoring a computer, and you can see it would
be reserved for the ones that are "significant."  

Keeping your computer off the phones and AC while doing crypto processing,
can be fairly easy.  Unplug the darn modem from the phone socket.  (Gee that
was simple, wasn't it?)  Use a laptop and run it entirely on the batteries
while doing crypto processing.  You can go buy an old laptop pretty cheaply
these days...  Or get an uninterruptable power supply for your main
computer; cost will vary from $600 to $1500 depending on how much time you
need to be running on the large batteries which are converted into AC to run
the computer.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 21 Oct 92 09:43:25 PDT
To: cypherpunks@toad.com
Subject: Keystone
In-Reply-To: <9210201753.AA009kv@fnordbox.UUCP>
Message-ID: <9210211643.AA11195@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Eric:
>:I would be hesitant to implement a system that _only_ required a user
>:to generate a key pair.

Loyd:
>I take the opposite view -- I dare *not* supply such a system. 
[...]
>But many users do not have the interest/time/ability to set up PGP on their
>home system. For them, I want to provide the best possible privacy given the
>ease with which anyone who can find their local LMOS can tap (voice or data)
>a line...

Where is the key pair generated?  It must be on the BBS since your
user may not have PGP running.  The private key isn't private!  The
work to do public key encryption in the first place is hardly valuable
if the owner of the private key doesn't hold it.

If you just want inter-BBS privacy, why not set up each BBS with a PGP
key pair, and use that for transfering messages?  There's not much
difference in security.  A monitoring sysop would be able to read all
the traffic originating on that board in either system.  The
difference is that such a monitoring sysop would not be able to read
replies.  Why?  Because the private keys are kept on the originating
board.

But it sounds as though you're trying to prevent against external
monitoring and that you trust your sysops.  In this case there is no
advantage to issuing keys to individuals; it's just not worth the
effort.

Loyd:
>I don't have my user's terminal program -- I *do* have the bbs software.

This is the unfortunate fact of the situation, I acknowledge.  But do
you know what terminal programs are in the most common use?  I suspect
most of this stuff could be done with script programming in the
various terminal packages.

Do you know, in aggregate, how many users of each terminal program you
have?  You can poll your users to find out.  You'll need this data to 
allocate your effort.

And you've got lots of people willing to help, even if they can't
because they are working on other projects.  Everyone on this list,
for example.  Let me repeat, for those of you who did not previously
know you were willing to help.  Everyone on this list should be
willing to help Loyd write scripts for his users to use PGP.  

Cypherpunks write code.

This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix,
etc.  for the PC, someone who knows the various Mac, Amiga, Atari, and
other machines.  This will mean someone to write nice pretty visual
interfaces for PGP to put all the PGP options on menus where they are
all visible.  This will mean people to think about BBS/terminal
protocols.  This will mean lots of individual contributions, no single
of which need be large, but whose sum will be.

Eric





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 21 Oct 92 10:11:42 PDT
To: cypherpunks@toad.com
Subject: TEMPEST, Eavesdropping
In-Reply-To: <9210202224.AA28714@netcom2.netcom.com>
Message-ID: <9210211711.AA11833@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>Their chief concern doesn't seem to be folks like us, but rather
>concerns about vans parking outside high tech and defense contractors
>and slurping up what they can [...]

When banks start signing with private keys, then we get an even more
interesting monitoring problem.

>And someone asked about building Faraday cages. Don't even try! 

Sometimes it is cheaper to build a whole building to be tempest-spec
than to buy all tempest-spec electronics.  What I have heard about
such stuff is solid copper walls and no windows.  No exacly your
classical Faraday cage; more like your classical Gaussian surface. :->

TEMPEST is an acronym.  I don't remember for what.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 21 Oct 92 10:13:36 PDT
To: cypherpunks@toad.com
Subject: another service
In-Reply-To: <9210202353.AA04723@soda.berkeley.edu>
Message-ID: <9210211713.AA11854@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: digital timestamping.  Eric Hollander says:
>Ideas?  Thoughts?

Yes.  Send code.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Wed, 21 Oct 92 08:23:37 PDT
To: tcmay@netcom.com
Subject: another service
In-Reply-To: <9210210014.AA05539@netcom2.netcom.com>
Message-ID: <9210211427.AA03115@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: tcmay@netcom.com (Timothy C. May)

>Eric Hollander writes:

>> I have thought of another service, like the depository, which might be
>> useful to the user community:  a time stamping notary service.  This would
>> have less security problems than the depository and would also be neccessary
>> if RSA'ed documents are to replace contracts and other paper documents used
>> in business.

>Bellcore is offering some form of this service, or plans to. Stuart
>Haber, one of the codevelopers, described this at last year's Hackers
>Conference and presented a paper at the Crypto '90 conference, or
>possibly the Crypto '91. (I have a Xerox of the paper someplace and
>may be able to dig it up if you're interested)

Haber isn't offering quite the service described -- he worked out a
much nicer notarization and time stamping protocol thats really neat.
Every day or two a critical number spat out from the service gets
published in the classifieds of the New York Times so people can
independantly verify that there is no cheating. By the way,
technically, the service doesn't do timestamping, just a verified
ordering of notarized documents. Unfortunately, there is no
mathematically provable way to know what time it is -- you must trust
someone on that.

Stu's a really nice guy -- maybe someone should encourage him to join
this list.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Wed, 21 Oct 92 13:26:56 PDT
To: cypherpunks@toad.com
Subject: the acronym TEMPEST
Message-ID: <9210212026.AA00628@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



> TEMPEST is an acronym.  I don't remember for what.

> Eric

TEMPEST = Transient ElectronMagnetic Pulse Emission STandard.  Pretty
cool sounding acronym :-)

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Wed, 21 Oct 92 14:07:37 PDT
To: cypherpunks@toad.com
Subject: TEMPEST, Eavesdropping
In-Reply-To: <9210211711.AA11833@soda.berkeley.edu>
Message-ID: <9210211934.AA09886@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain



>From: Eric Hughes <hughes@soda.berkeley.edu>

>>Their chief concern doesn't seem to be folks like us, but rather
>>concerns about vans parking outside high tech and defense contractors
>>and slurping up what they can [...]

>When banks start signing with private keys, then we get an even more
>interesting monitoring problem.

Consider that the international clearing and settlement systems for
interbank transactions process several TRILLION a day in electronic
transactions, and then consider what diverting just a tiny little bit
of that to yourself would be worth. Security in banks is ALREADY
crucial.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Wed, 21 Oct 92 13:44:45 PDT
To: cypherpunks@toad.com
Subject: fast elliptical encryption
Message-ID: <9210212044.AA00695@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



In the winter NeXTWorld magazine, the article ("Tales from the Crypt")
on page 94 mentions various topics of interest: public key encryption,
export restrictions, the role of the NSA, etc.  (It's just a one page
article and doesn't go into much depth).

Anyway, NeXTStep 3.0 is bundled with fast elliptical encryption for
NeXTMail.  As a result, 3.0 is export restricted.

Does anybody know about the "fast elliptical encryption" public-key
system?  How different is it from good ol' RSA?  Is it related to the
elliptic-curve factoring algorithm (am I remembering this correctly -
I don't know how elliptic curve factoring works, but I remember seeing
a reference to it somewhere)?

Just curious...

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Campbell James A" <UJACAMPBE@memstvx1.memst.edu>
Date: Wed, 21 Oct 92 14:29:41 PDT
To: "cypherpunks" <cypherpunks@toad.com>
Subject: Put me on your mailing list!
Message-ID: <9210212129.AA27437@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Hey, I'd like to be on the mailing list for CYPHERPUNKS.  My address is:

                     ujacampbe@memstvx1.memst.edu

If you need this too, here's my PGP 2.0 public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0
 
mQCNAirkL4AAAAEEANAomYnlPXopnms9RtU0ln9CiLJljssOeflC9A+QIDujXhPT
yApbL6VPqSUSoFF/e72xTJixyrwBQhw5lAvfvQPEiGIFQQYxviF+Qg/+6/JVvLCj
vnGVFl9kKTEYVeONxBNGiaXuSE0VMQLx47iP9AU+wYw62aXmTNtW1BUtX5BHAAUR
tDBKYW1lcyBBLiBDYW1wYmVsbCA8dWphY2FtcGJlQG1lbXN0dngxLm1lbXN0LmVk
dT4=
=0rCj
-----END PGP PUBLIC KEY BLOCK-----
 

Thanks!


James A. Campbell

Memphis State University
Memphis, Tennessee





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 21 Oct 92 22:35:21 PDT
To: cypherpunks@toad.com
Subject: Keystone
In-Reply-To: <9210220333.AA009m7@fnordbox.UUCP>
Message-ID: <9210220541.AA13526@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Ah.  A small PGP subset.  You hadn't mentioned this.  When you said
you weren't requiring the user to run PGP, I assumed key generation
must occur on the board.

As for your fatal flaw I hadn't spotted, I had spotted it, and the
location of the private key was the critical point.  If the key is on
the BBS, the message goes out in the clear.

Look, it boils down to this.  If the message traffic to the BBS is to
be encrypted, then the user has to generate a key on his own machine
and decrypt it on his own machine.  There's no way around that.

But the user interface problem can be solved.  Just make a bunch of
.com files which do nothing but spawn pgp by invoking the correct
arguments.  Very simple; a few lines of C is all.  Even the PGPPATH
can be set before the spawn.  It's an easy encapsulation.  It will run
a bit slower for load time, but not appreciably.  And you won't have
to recompile PGP from the distributed executables.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Wed, 21 Oct 92 23:35:44 PDT
To: Eric Hughes <hughes@soda.berkeley.edu>
Subject: Re: Keystone
In-Reply-To: <9210220541.AA13526@soda.berkeley.edu>
Message-ID: <9210220637.AA20200@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


We have a small project cooking, to use Diffie-Hellman key exchange
to choose a random key to encrypt Internet connections (telnet,
rlogin, ftp, smtp).  This same protocol can also be used over an
ordinary modem connection between a user's PC and a BBS, preventing
eavesdropping or wiretapping of that phone call.  It would also be
able to protect phone calls between a PC and a Unix timesharing system,
regardless of what networks lie in between, if we wrote a simple login
program that handled the modem protocol.  (It doesn't protect against
active re-routing of the call, e.g. by substituting another machine
for the BBS, but we could work on that as Phase II.)

(I suggest that the initial Diffie-Hellman handshake all be done in
ASCII encoding, no matter what the medium, so that the same protocol
can be used on all media, binary-transparent or not.)

This scheme would require support in the BBS and in the user's PC
terminal program.  Given a working Unix implementation, it would be
relatively easy to add to the terminal program, if source code for any
decent terminal programs was available.  This is where Unix shows a
real advantage, since you can get free source for just about program,
while "free" PC programs means free binaries.  If anyone knows of a
reasonably popular PC terminal emulator for which source code is
freely available and distributable, let us know.

(Or, if anyone knows the author of a popular commercial PC terminal
emulator program, tell the author that they could consider licensing
Diffie-Hellman from RSA for commercial use and adding it to their
proprietary terminal program.  They're unlikely to do so, since it
costs money, unless some very popular BBS's can also be upgraded to do
it -- standard commercial chicken/egg problem which free source code
solves.)

On the BBS side, I've heard the idea of freeing the Fido source code
as copylefted code.  That would make it easy to add things like login
session encryption for the modem users.

	John Gilmore




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Thu, 22 Oct 92 00:00:52 PDT
To: cypherpunks@toad.com
Subject: "Cypherpunks write code"
Message-ID: <2580@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


Eric Hughes writes:

> 
> Cypherpunks write code.
> 
> This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix,
> etc.  for the PC, someone who knows the various Mac, Amiga, Atari, and
> other machines.  This will mean someone to write nice pretty visual
> interfaces for PGP to put all the PGP options on menus where they are
> all visible.  This will mean people to think about BBS/terminal
> protocols.  This will mean lots of individual contributions, no single
> of which need be large, but whose sum will be.
> 
> Eric
> 

Count me in on the Procomm scripting.  I *may* do something for Telix,
too.

Who knows?  I may sell the scripts/interfaces on AMiX.   ;-)


Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
================ PGP 2.0 public key available =======================




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 22 Oct 92 08:51:19 PDT
To: cypherpunks@toad.com
Subject: Keystone
Message-ID: <9210221550.AA23915@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: adding D-H key exchange to PC software

gnu@cygnus.com writes:
>Given a working Unix implementation, it would be relatively easy to
>add to the terminal program, if source code for any decent terminal
>programs was available.

But source code is not available.  The trouble is that all the decent
terminal programs for PC's are shareware or commercial (or were
originally shareware and have become commercial).  I too would like to
know of any source-available PC terminal programs, but I suspect there
are none because of the prevailing shareware culture.


Re: getting an author to license D-H key exchange

The reason this will not happen is not the bootstrapping problem
(chicken/egg), but that there is no perceived value to an encrypted
link.  The sysop is already has access to everything on the dedicated
machine and may even have a policy of scanning all messages.  External
hackers can't really get in because shell access isn't really done
remotely.  The only ones you are protecting against are people with a
hard tap on the phone line itself.  For most people, this is not a
concern.

Since there's no perceived value and since all the software would
require license from RSADSI, it won't happen that way.


Re: using a protocol layer

avalon@coombs.anu.edu.au writes:
>Rather than rewrite the terminal progs, why not rewrite the BIOS level
>drivers and such ? (if its possible).

That's not possible either.  Most terminal programs write directly to
the hardware.  This is single-tasking, standardized hardware,
remember, and the original BIOS interface for the serial port was
totally unusable.  Some communications programs use FOSSIL drivers,
but many (if not most) terminal programs don't support it.  (FOSSIL is
a BIOS-level serial port interface description which could hooked into
or rewritten to support a protocol.)


Look, I wish all this stuff were in use.  Everyone should encrypt all
their communications links as a matter of policy.  (That includes
voice, and if you thought the PC terminal program bootstrapping was
difficult ...)  Let's move incrementally, though.  If we can get
people to at least encrypt all of their e-mail, that will be an
excellent start.

One incentive would be for the BBS operators to phase in a policy that
they will accept no e-mail which is _not_ encrypted.  Comments?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Thu, 22 Oct 92 10:52:24 PDT
To: cypherpunks@toad.com
Subject: re: Keystone
Message-ID: <3225.2AE6E91B@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain




re: PGP interface to email.

I've completed my "RM" program. The PGP interface is
single-keystroke, and includes optional pass-phrase management. 

I've released it with source under the copyleft agreement. It can be
downloaded or filerequested from me if anyone's interested. 

(MSDOS and .MSG format only)

--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnordbox!loydb@cs.utexas.edu (Loyd Blankenship)
Date: Thu, 22 Oct 92 08:33:10 PDT
To: soda.berkeley.edu!hughes@cs.utexas.edu
Subject: Re: Keystone
Message-ID: <9210221550.AA009mh@fnordbox.UUCP>
MIME-Version: 1.0
Content-Type: text/plain



:But the user interface problem can be solved.	Just make a bunch of
:.com files which do nothing but spawn pgp by invoking the correct
:arguments.  Very simple; a few lines of C is all.  Even the PGPPATH
:can be set before the spawn.  It's an easy encapsulation.  It will run
:a bit slower for load time, but not appreciably.  And you won't have
:to recompile PGP from the distributed executables.

That's a real good idea. I shoulda thunk of it myself. :-)

Loyd

***************************************************************************
* loydb@fnordbox.UUCP	     Once you pull the pin,  *	Loyd Blankenship  *
* GEnie: SJGAMES	    Mr. Grenade is no longer *	PO Box 18957	  *
* Compu$erve: [73407,515]	 your friend!	     *	Austin, TX 78760  *
* cs.utexas.edu!dogface!fnordbox!loydb		     *	512/447-7866	  *
***************************************************************************




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Thu, 22 Oct 92 11:19:49 PDT
To: cypherpunks@toad.com
Subject: re: Keystone
Message-ID: <3230.2AE6EFBC@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Hughes:
 U> But source code is not available.  The trouble is that all 
 U> the decent terminal programs for PC's are shareware or 
 U> commercial (or were originally shareware and have become 
 U> commercial).  I too would like to know of any 
 U> source-available PC terminal programs, but I suspect there 
 U> are none because of the prevailing shareware culture. 
 U> 

I'll give you all of my Fido/FidoNet and FidoTerm sources. You can
already have ReadMail.

 U> communications programs use FOSSIL drivers, but many (if 
 U> not most) terminal programs don't support it.

Commercial people still sneer at amateur systems like FidoNet. Their
loss. FOSSIL is widely supported otherwise. FidoTerm and Fido/FidoNet
both support FOSSIL, as do "all" FidoNet programs.

 U> One incentive would be for the BBS operators to phase in a 
 U> policy that they will accept no e-mail which is _not_ 
 U> encrypted.  Comments? 

SHEESH!@+#)(#$ You oughta see what most sysops think. It's
embarrassing. In their defense, NO ONE WILL TELL US what is
reasonable. I know, I know how much is presently undefined and without
precedent, but the broadest general parameters and guidelines are not
that obscure. 

I'm also part of the BBSLAW mailing list (out of EFF) and it's
finally contained some applicable stuff. What you wanna bet the
lawscum won't let me repeat in any manner the recent thread on email?
(Yes I'm asking.)

(Most sysops are terrified that an in-transit, third-party message
will contain some illegality and they will all be BUSTED. Hence, it
is routine for them to review personally every in-transit message,
and kill or bounce them! I am not kidding. 

(I know this must have been dealt with in the Internet (is
kumr/cygnus/etc liable when I tell you that RICHARD NIXONS VISA CARD
NUMBER is 4131 34534 456456 456546?) but somehow, no one's ever
passed this info on to us.)


--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG

rom fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings@kumr.lns.com  Thu Oct 22 11:19:49 1992
Return-Path: <fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings@kumr.lns.com>
Received: from kumr.lns.com by toad.com id AA22497; Thu, 22 Oct 92 11:19:49 PDT
Received: by kumr.lns.com (/\==/\ Smail3.1.25.1 #25.3)
	id <m0mi78E-0000hbC@kumr.lns.com>; Thu, 22 Oct 92 11:19 PDT
Received: by fidogate.FIDONET.ORG (mailout1.26); Thu, 22 Oct 92 11:15:22 PDT
Date: Thu, 22 Oct 92 11:03:26 PDT
Message-Id: <3229.2AE6EFB9@fidogate.FIDONET.ORG>
From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
Subject: thread (was Re: A
To: cypherpunks@toad.com
X-Mailer: mailout v1.26 released


Just a slightly amusing message forwarded from PUBLIC_KEYS...



From:      Wes Cowley@1:125/180
To:        Wes Perkhiser@1:125/111
Subject:   Loss of thread (was Re: A
;Status:   (read 2 times)
;^AINTL 1:125/111 1:125/180
;^APID ReadMail
;^AMSGID RM1:125/111=2AE68513
>----------------------- Do not change this line -----------------------------<
WP>>"Hi, how are you, and what's your key?"
WP>>P.S.  Will that be a new pick-up line?  It beats "What's your sign?"

"Do you want to swap keys, or just come up to my pad, one time?"

 * OLX 2.1 TD * The computing field is always in need of new cliches.

--- DCI/Chauncy 0.7
 * Origin: Bird Lake - (813)265-3256 (1:377/14.0)
SEEN-BY: 100/520 102/890 105/36 125/111 125 180 185 135/71 340 163/438 170/109
SEEN-BY: 216/21 234/1 253/513 261/1136 285/27 312/2 374/14 26 48 98 377/3 14 15
SEEN-BY: 377/33 37 396/1 2200/101
;;
--  
tom jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: sdw@meaddata.com (Stephen Williams)
Date: Thu, 22 Oct 92 10:09:30 PDT
To: gnu@cygnus.com
Subject: Re: Keystone
In-Reply-To: <9210220637.AA20200@cygnus.com>
Message-ID: <9210221600.AA21898@bugatti.meaddata.com>
MIME-Version: 1.0
Content-Type: text/plain


..
> real advantage, since you can get free source for just about program,
> while "free" PC programs means free binaries.  If anyone knows of a
> reasonably popular PC terminal emulator for which source code is
> freely available and distributable, let us know.
PC Kermit, of course.  The best vt100 emulator around, last I used them
heavily.
> 

sdw
-- 
Stephen D. Williams  Local Internet Gateway Co.; SDW Systems 513 496-5223APager
LIG dev./sales       Internet: sdw@world.std.com CIS 76244.210@compuserve.com
OO R&D Source Dist.  By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342
GNU Support          ICBM: 39 34N 85 15W I love it when a plan comes together




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: omega@spica.bu.edu (The Omega)
Date: Thu, 22 Oct 92 09:25:56 PDT
To: cypherpunks@toad.com
Subject: BBS E-mail policy
Message-ID: <9210221623.AA00440@spica.bu.edu>
MIME-Version: 1.0
Content-Type: text/plain


>>
One incentive would be for the BBS operators to phase in a policy that
they will accept no e-mail which is _not_ encrypted.  Comments?
<<
 
And how does your BBS software tell whether or not you've just sent
encrypted mail, plaintext mail or line-noise?
(in an encryption/decryption-at-user's-end scenario)
 
-- Omega@spica.bu.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Scott Collins" <scott_collins@genmagic.com>
Date: Fri, 23 Oct 92 00:06:14 PDT
To: "Cypher Punks" <cypherpunks@toad.com>
Subject: Diffie-Hellman
Message-ID: <9210230706.AA04122@relay2.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


Subject:  Diffie-Hellman

>Since there's no perceived value and since all the software would
>require license from RSADSI, it won't happen that way.

It was not my understanding that RSA held any patents, copyrights or other controls
over Diffie-Hellman key exchange.  The 'big-number' math required is not
difficult and is fully documented in Knuth's "The Art of Computer Programming",
vol2: Seminumerical Algorithms; section 4.3: Multiple Precision Arithmetic. 
Also note that this multiple precision code is available in the PGP source in
the file mpilib.c.

The exchanged key could easily be a DES (or other fast symmetric cypher) key --
and usually is.  Unless you want to perform an authenticated key exchange with
Diffie-Hellman as described in "Authentication and Authenticated Key Exchanges" [Diffie,
Van Oorschot and Wiener in "Designs, Codes and Cryptography", 2, 107-125 (1992)]
using certificates signed with the RSA algorithm, then RSA doesn't have to enter
the picture at all.

Is my understanding of RSAs controls incorrect?





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Thu, 22 Oct 92 13:35:59 PDT
To: gnu@cygnus.com
Subject: Keystone
In-Reply-To: <9210220637.AA20200@cygnus.com>
Message-ID: <9210221929.AA16268@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: gnu@cygnus.com

>We have a small project cooking, to use Diffie-Hellman key exchange
>to choose a random key to encrypt Internet connections (telnet,
>rlogin, ftp, smtp).  This same protocol can also be used over an
>ordinary modem connection between a user's PC and a BBS, preventing
>eavesdropping or wiretapping of that phone call.  It would also be
>able to protect phone calls between a PC and a Unix timesharing system,
>regardless of what networks lie in between, if we wrote a simple login
>program that handled the modem protocol.  (It doesn't protect against
>active re-routing of the call, e.g. by substituting another machine
>for the BBS, but we could work on that as Phase II.)

I would suggest that it be done during phase one. Spoofing attacks are
very important things to guard against, and thanks to PGP there is a
handy dandy set of code out there to steal from to provide for public
key based authentication of the link. Indeed, I would go further and
suggest that the protocol be designed so that it does not reveal the
entities forming the link to outsiders (unless one end should
intentionally advertise who it is, the assumption should be that both
ends know who the other end is a priori). There is also a very good
implementation of the IDEA cypher in PGP, which should run well as the
conventional cypher for the link (although I would suggest having the
protocol negotiate the cypher just in case IDEA gets replaced later
on).

I am very interested in seeing such a protocol standardized because I
have another use for it -- secure telephones. Given modern DSPs to do
and cheap V.32bis modems, excellent secure voice communications are
feasable. The presense of code in the public domain to handle secure
encrypted links could be easily dropped right in to this application.

>(I suggest that the initial Diffie-Hellman handshake all be done in
>ASCII encoding, no matter what the medium, so that the same protocol
>can be used on all media, binary-transparent or not.)

I agree that this should be a negotiated option in the protocol
(prehaps with some sort of test done at the beginning of the link for
line transparency), but I'm not sure it should be mandatory as that
eighth bit get significant at times.

>If anyone knows of a reasonably popular PC terminal emulator for
>which source code is freely available and distributable, let us know.

Kermit is the obvious choice.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: jjaloszyns@bluejay.mich.fred.org
Date: Fri, 23 Oct 92 10:04:47 PDT
To: cypherpunks@toad.com
Subject: TEMPEST
Message-ID: <9210231704.AA25073@home.merit.edu>
MIME-Version: 1.0
Content-Type: text/plain


There has been quite a bit of concern about certain people (agencies)
using a TEMPEST machine and invading privacy.  Most of the things to
defeat this that have been taked about have revolved around shielding. 
What would be the problem with having another device to emit random
signals on the same frequency that your monitor operates on?  Has this
already been implimented?  Legal?  
 
jon

<jjaloszyns@bluejay.mich.fred.org> ------------- 43.31.28N, 84.41.41W 
Jon Jaloszynski
Student 9-12 at Shepherd HS,  Shepherd                     Shepherd, MI





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: bill@anubis.network.com (Bill O'Hanlon)
Date: Thu, 22 Oct 92 14:13:15 PDT
To: cypherpunks@toad.com
Subject: Re: Keystone
In-Reply-To: <9210221929.AA16268@newsu.shearson.com>
Message-ID: <9210222112.AA06121@anubis.network.com>
MIME-Version: 1.0
Content-Type: text/plain


>
>I am very interested in seeing such a protocol standardized because I
>have another use for it -- secure telephones. Given modern DSPs to do
>and cheap V.32bis modems, excellent secure voice communications are
>feasable. The presense of code in the public domain to handle secure
>encrypted links could be easily dropped right in to this application.
>

I've had much the same idea.  There are a lot of people out there with 
PCs equipped with Soundblasters and V.32 modems.

I can't think of a better way to fight back against that ridiculous
FBI Telephone legislation.


-- 
Bill O'Hanlon               Network Systems Corporation
bill@network.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: DELTORTO@AppleLink.Apple.COM (Imaja, David Del Torto,PAS)
Date: Thu, 22 Oct 92 16:28:44 PDT
To: CYPHERPUNKS@TOAD.COM
Subject: temporary request
Message-ID: <719795393.8323950@AppleLink.Apple.COM>
MIME-Version: 1.0
Content-Type: text/plain


Greetings CypherFolk,
 
I, one of your newest members, am on vacation in Europe (right now I'm in
Holland enjoying the "coffee" shops) and am temporarily restricted to using
AppleLink as my gateway to Internet. Because it costs $0.50 to $0.80 per piece
of email, I asked Eric to _temporarily_ remove me from the general alias until
I return to the US in December, saving me major bucks. When I get back, I'll
announce that you can send me mail at "ddt@well.sf.ca.us". I enjoyed the
repartee I sampled and look forward to joining in as I learn more.
 
Offer of the Week:
If anyone needs me to physically pick up a PGP key from someone here in Europe,
I have a train pass good for another month (maybe longer if I can alter it
again) and will consider any request that will take me to interesting locations
and connect me with interesting folks.
 
Further Request:
If any of you send any interesting stuff to the group alias (e.g. Russ
Whitaker's article on "computer cryptography" from the Economist) and think it
might be of general interest to someone learning about the whole encryption
process (i.e. me), please cc me at "deltorto@applelink.apple.com" anytime. This
would be appreciated. I also encourage anyone who has helpful learning material
to forward it to me so I can get up to speed. I am working on an interesting
project I would like to share with the right people, but I am not prepared to
discuss it in public.
 
Does anyone have a copy of PGP 2.0 that runs on a Macintosh? If you email it to
me, I will cover any costs you incur. Coolness.
 
Until we all meet in person,
 
    dave
 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 22 Oct 92 23:02:09 PDT
To: cypherpunks@toad.com
Subject: BBS E-mail policy
In-Reply-To: <9210221623.AA00440@spica.bu.edu>
Message-ID: <9210230601.AA26160@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: distinguishing between encrypted mail, plaintext mail, and
line-noise.

I'm really glad this question came up.  I passed over it before
because I was more interested in the social issue, but the technical
one is important.

The basic technique is the foundation of cryptography: information
theory.  For this application, you can just measure the entropy; it
alone should be able to distinguish between the three sources.  The
entropy measures how well one can statistically predict the output of
a source.  A random source has eight bits of entropy per byte.  As
randomness decreases, so does the entropy measure.  (Mail me if you
want references in order to learn this stuff yourself.)

Now line noise, let's say, will appear random.  So its entropy should
be right near the maximum, 8 bits.  Text encrypted with PGP using the
ASCII armor uses only 64 characters out of 256 possible, or one fourth
of the total available.  Its entropy would be 2 bits per character.
English text is usually around four and five bits per character, if I
remember right.

To calculate the entropy, you first make a table (of size 256) of
character frequencies normalized to the range [0,1].  Call these p_i.
The entropy is then (TeX here) $ \Sum_{i=0}^{256}n - p_i \log_2 p_i $.
(The log base 2 give bits instead of natural units).

Now see if this number is in one of the following ranges:

	[1.5 .. 2.5]	encrypted text
	[3 .. 6]	regular text
	[7 .. 8]	line noise

This is a very simple measure.  There are other measures to look for
the deviation from an expected distribution, which give much more
accurate distinctions.  One can very easily separate languages from
each other just by looking at such measures.

Note that none of these techniques ever look at the content.  Nor do
they look at digraph (two-letter combinations) or trigraph statistics.
In fact, the content is completely destroyed by the scanning process!
Lots of this stuff is known; this is how the big boys crack codes.
I'm glad there arose a natural context to explain some of this stuff.

Eric





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Thu, 22 Oct 92 23:10:13 PDT
To: cypherpunks@toad.com
Subject: Eavesdropping on a printer's signature
Message-ID: <9210230609.AA26646@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


While doing a summer (1980?) co-op with Raytheon Submarine Signal
division in Newport RI, a milk-truck-sized van pulled up out front
and opened a sliding side door.  Inside was a line printer
that was busy printing out the same text that an internal (in the
middle of the building, perhaps 150 feet away) line-printer was
printing.   There were mistakes, but it was readable.

My guess is that with all the electromechanical pulses the printer
was emanating this was pretty easy.  Probably harder to do with a
laser printer...




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 22 Oct 92 23:22:28 PDT
To: cypherpunks@toad.com
Subject: Keystone
In-Reply-To: <3230.2AE6EFBC@fidogate.FIDONET.ORG>
Message-ID: <9210230622.AA26831@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: about a policy to require encrypted email.

Here is a statement I would like to see become policy and law:

"A provider of communications services cannot be held liable for the
consequences of encrypted communications that pass though its system."

Here is the argument to support it.  If I am a common carrier, I am
already off the liability hook by the nature of common carrier.
Suppose I am not a common carrier, for example because I provide a
value-added service such as electronic mail.  Also suppose that I
can't observe the contents of traffic that flows through my system
because it is encrypted.  Then I have no means to take any action
whatsoever with regard whatever consequences might occur from that
traffic.  I cannot be held responsible for actions I cannot take, much
less know of the existence of.

Such a policy would give BBS operators a complete defense against
claims of liability arising from email traffic.  It doesn't solve the
problem for public discussion areas, but it's a good start.  It would
also drive the deployment of encryption technology.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: avalon@coombs.anu.edu.au (Darren Reed)
Date: Thu, 22 Oct 92 06:55:03 PDT
To: cypherpunks@toad.com
Subject: terminal progs to do pgp...
Message-ID: <9210221354.AA06975@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain



Rather than rewrite the terminal progs, why not rewrite the BIOS level
drivers and such ? (if its possible).

At least this way, it would be one hack which would work on all terminal
programs...you'd just need a way to turn it on/off which I'm sure wouldn't
be that hard :-)

cheers,
darren




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Fri, 23 Oct 92 00:28:19 PDT
To: cypherpunks@toad.com
Subject: Re: Keystone
In-Reply-To: <9210230622.AA26831@soda.berkeley.edu>
Message-ID: <9210230728.AA25822@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


> "A provider of communications services cannot be held liable for the
> consequences of encrypted communications that pass though its system."

Far too simple.  Suppose the provider is a BBS operator who *knows* what
their users are passing through the system?  Suppose the provider has
keys to the encrypted communications?  Suppose those keys are only to be
used under duress (e.g. under a court order)?  Suppose the provider
is a parent and the user is their teenage daughter?  Suppose the
encryption is easily breakable?

The principle you are looking for is that if the service provider has
no *control* over the content, then they should have no *liability*
for it either.  The courts are gradually making that happen.  But
control relates directly to the specific facts of the particular case --
not whether encryption is in use.

The case law on liability for content is gradually being made.  So
far, no particularly horrible precedents have been set (I don't think
there are precedents yet in the arrest-the-record-store-owner-for-rap-
records-the-cops-don't-like issue).  In a good decision, Compuserve
was let off the hook for a message sent by someone who Compuserve even
paid to moderate a corner of their service -- because Compuserve
didn't control the content of that corner.

I realize that this group has a tendency toward extremism, but let's
temper that with a bit of wisdom, too.

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 23 Oct 92 02:31:20 PDT
To: omega@spica.bu.edu
Subject: Re:  BBS E-mail policy
Message-ID: <199210230930.AA18783@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



Eric, count this as another vote for default encryption of all
communications links.  

Omega: the way to tell is to run a frequency count on the text.  If it
follows the usual distribution for the language it's in, then it's probably
plaintext.  In which case the BBS rejects it.  

Voice: yeah, it's a pain in the tail. One thing I thought might be
interesting is to use two digitisers: one for the voice input, another for a
keystream which is derived from a radio or TV program signal which can be
picked up simultaneously by both correspondents.  XOR the two streams
together and then do whatever you have to do to make the encrypted results
transmissable.  I actually tried building an analog version of this about
ten years ago (might even bring it to one of our meetings, just for fun).
Analog voice "encryption" is actually pretty worthless (I didn't know how
worthless until I experimented with it) from a security standpoint.  

Voiceprint modification may have some uses.  About five or six years ago I
built one of those: based on a pitch shifter with a graphic EQ on the input
side and another on the output side.  Worked, sort of.  Now there is a
phone you can buy with something similar built in.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 23 Oct 92 02:39:14 PDT
To: hughes@soda.berkeley.edu
Subject: Re:  Keystone
Message-ID: <199210230938.AA18939@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



Re BBSs and encrypted email.  Of course it would eliminate liability; well
I would expect the Powers That Be to simply outlaw the use of encryption on
BBSs or find some legal convolution which has a similar result.  The only
way we can win on this is to do what we're doing: get this stuff out there
far & wide before anyone has a chance to stop it.  
-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 23 Oct 92 09:30:05 PDT
To: cypherpunks@toad.com
Subject: Diffie-Hellman
In-Reply-To: <9210231456.AA20396@anchor.ho.att.com>
Message-ID: <9210231629.AA10278@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>I'm pretty sure Public Key Partners (closely related to RSA) holds
>the patent, just as they hold RSA's.

This is what I remember about PKP.  Public Key Partners is a
consortium of four, two industry and two academic members.  RSA Data
Security and Cylink are the industry partners.  I believe that
Stanford and MIT are the academic ones.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Fri, 23 Oct 92 14:46:09 PDT
To: uunet!soda.berkeley.edu!hughes@uunet.UU.NET
Subject: Keystone  "A provider of communications services cannot be held liable for the consequences of encrypted communications that pass though its system."
In-Reply-To: <9210230622.AA26831@soda.berkeley.edu>
Message-ID: <9210231631.AA11756@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


The Compuserver decision some months ago supported this indirectly:
Compuserver was held not liable for mail and postings on their system,
because they don't claim to read them.  I don't beleive Compuserve is
a common carrier, so the precedence supports the result you want.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Fri, 23 Oct 92 14:48:24 PDT
To: cypherpunks@toad.com
Subject: Call for papers
Message-ID: <9210231638.AA11816@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain



                         Call for Papers

  
 "Technological Strategies for Protecting Intellectual Property 
            in the Networked Multimedia Environment"


          Cambridge, Massachusetts, February 3-5, 1993

                          sponsored by:


               Coalition for Networked Information
   
               Information Infrastructure Project
Science, Technology and Public Policy Program, Harvard University

               Interactive Multimedia Association
       
        Program on Digital Open High Resolution Systems,
              Massachusetts Institute of Technology




This workshop will map the territory between security issues and 
the need for practical, user-friendly systems for marketing 
information resources and services.  It will survey the 
technological landscape, evaluate the potential benefits and 
risks of different mechanisms, define a research agenda, and 
frame related implementation and policy issues.  The workshop 
will give special attention to how and where within the overall 
infrastructure different technologies are best implemented.  It 
will present and analyze models for explaining protection systems 
and strategies.

Papers are invited on the foregoing and on the capabilities and 
relationship of the following technologies and strategies:

     -- billing servers 
     -- type of service identifiers, header descriptors, and 
          other forms of labeling and tagging 
     -- fingerprinting
     -- digital signatures
     -- contracting mechanisms and EDI licensing of intellectual 
          property 
     -- copy protection and serial copy management
     -- authentication servers and site licensing
     -- software envelopes 
     -- encryption 
     -- display-only systems
     -- concurrent use limitations 
     -- structured charging
     -- technology assessment and risk analysis 

The workshop will be held at MIT and Harvard on February 3-5, 
1993.  Participation at the two-day event would be limited to 35-
40 invitees, but the papers will be revised for publication as 
part of Information Infrastructure Project's publication program.
                          
Abstracts of proposed papers should be sent to: 

Thomas Lee
DOHRS/CTPID
MIT
E40-218
Cambridge, MA 02139
tlee@farnsworth.mit.edu
617-253-6828
Fax: 617-253-7326 or 617-253-7140
________________________________________________________________


The global Internet offers the beginning of a networked, 
multifunctional, multimedia environment for both resource-sharing 
and marketing information products and services.  Although 
underlying technologies may change, the applications and 
practices developed now are shaping the universal broadband 
infrastructure of the future.  

However, concern for copyright protection remains a major 
impediment to private investment in information resources and 
services.  Owners of information resources are fearful of 
releasing proprietary information to an environment which appears 
lacking in security and has no accepted means of accounting for 
use and copying.  Complex library systems may be designed and 
developed around nonproprietary information, but until there are 
mechanisms to accommodate proprietary information, the utility of 
the systems will remain limited by the nature of the material 
made available.  

Information technology enables the vision of a distributed, 
interoperating multimedia environment in which information from a 
universe of different sources can be combined and recombined to 
meet specific user needs.  Ironically, the vision is threatened 
by the absence of systematic controls.  

Mindful of this problem, Congress directed that the National 
Research and Education Network (the follow-on to the federally 
funded portion of the Internet) -- 
 
     (1) be developed and deployed with the computer, 
     telecommunications, and information industries....

     (5) be designed and operated so as to ensure the 
     continued application of laws that provide network and 
     information resources security measures, including 
     those that protect copyright and other intellectual 
     property rights....

     (6) have accounting mechanisms which allow users or 
     groups of users to be charged for their usage of 
     copyrighted materials available over the Network.... 
     [15 USC 5512(c)]

The Act also requires the Director of the Office of Science and 
Technology Policy to report to Congress by the anniversary of the 
Act (i.e., December 9, 1992) on "how to protect the copyrights of 
material distributed over the Network...." [15 USC 5512(g)(5)]

Despite this statutory language, federal agencies have yet to 
address these issues.  Many believe that the protection of 
intellectual property on the NREN as on any network is a private 
sector problem which needs to be addressed at an applications 
level, not within the design of the network.  Indeed, these 
intellectual property problems are not new; to a large extent, 
they represent traditional copyright problems which have been 
exacerbated by electronic technology, digitization of 
information, personal computers, and less advanced forms of 
networking.  But the prospect of pervasive, high-bandwidth, 
interconnected wide-area networks presents the problems in the 
most complete context.

There is a tension between the goals of protection, on the one 
hand, and interoperation and usability, on the other, that has 
defeated technological solutions in the past.  ADAPSO's proposed 
hardware lock failed to gain industry acceptance, and software 
copy protection has been abandoned except in certain high-value 
niche markets.  The microcomputer software industry has come to 
rely on the threat of lawsuits in the vulnerable corporate 
environment as a means of copyright enforcement.  Nonetheless, a 
hardware-secured environment incorporating serial copy management 
has been mandated (as an amendment to the Copyright Act) for the 
next generation of digital audio technology.

In the emerging environment, the conventional distinction between 
products and services breaks down.  Products are networked, and 
network-accessible services are linked to products.  Rights must 
be acquired to cover all forms of delivery, because multiple 
delivery paths are likely and the dominant technologies and 
markets cannot be predicted with confidence.  On the other hand, 
the control and security offered by different technologies may 
also determine the choice of distribution paths.  For these 
reasons, the workshop will look at the networked multimedia 
environment as a whole, from mass-market products to specialized 
services.


                                                                           









From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Fri, 23 Oct 92 14:42:19 PDT
To: uunet!soda.berkeley.edu!hughes@uunet.UU.NET
Subject: BBS E-mail policy Now see if this number is in one of the following ranges:
In-Reply-To: <9210230601.AA26160@soda.berkeley.edu>
Message-ID: <9210231641.AA11868@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


		 [1.5 .. 2.5]	encrypted text
		 [3 .. 6]	regular text
		 [7 .. 8]	line noise

	 This is a very simple measure.  There are other measures to look for
	 the deviation from an expected distribution, which give much more
	 accurate distinctions.  One can very easily separate languages from
	 each other just by looking at such measures.

Where does uuencoded [compressed] binary lie?  I would suspect it lies
right around where encrypted text is.  Presumably straight encrypted
text is statistically random [7..8], but that when you8 encrypt to
just the ascii subset is when you lose the entropy.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 23 Oct 92 10:27:18 PDT
To: cypherpunks@toad.com
Subject: Keystone
In-Reply-To: <9210230728.AA25822@cygnus.com>
Message-ID: <9210231726.AA11213@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


My proposal:
> "A provider of communications services cannot be held liable for the
> consequences of encrypted communications that pass though its system."

First let me point out that this wording is intended to be clear, not
to be legally useful.  This wording cannot stand for itself without
reference to the rest of the body of law.  I never intended it to.

It is also a mistake to think that I am advocating the converse,
namely, that the provider would be responsible for all unencrypted
communications.  Nor do I think that this should be the only defense a
provider has available.

gnu:
>Far too simple.  Suppose the provider is a BBS operator who *knows* what
>their users are passing through the system?  

The defense of encrypted communications is not germane here.  Such
knowledge did not come from the communications because they were
encrypted.  If the provider could read them, then they weren't
encrypted to the provider.  Therefore such knowledge came from some
other source.  A claim that arises from such knowledge is not met by
this criterion.

The defense of encrypted communications is not a blanket defense.

>Suppose the provider has keys to the encrypted communications?

Then the defense does not apply.  If the provider has keys to the
communications, then they are not encrypted as far as the provider is
concerned.  The question is not the _form_ of the communications, but
their _legibility_.

>Suppose those keys are only to be used under duress (e.g. under a
>court order)?

If the keys are in the possession of the provider and the provider and
the user have an agreement that the provider is not to use them in any
way other than archiving them, then the law cannot expect the provider
to routinely breach that agreement to search for possibly illegal
content.  The court may then subpoena these keys if necessary.

>Suppose the provider is a parent and the user is their teenage
>daughter?

The defense of encrypted communications is not germane here.  There is
a parent/child relation which creates a claim which the encrypted
communication defense is irrelevant to.

>Suppose the encryption is easily breakable?

The test of due diligence may be applied.  If the state of the art is
that the encryption is unbreakable, then the communications should be
consider to be encrypted.  If the cipher is automatically crackable,
such as monoalphabetic substitution, then the communications should be
consider _not_ encrypted.  Remember, the question is not _form_, but
_legibility_.

>The principle you are looking for is that if the service provider has
>no *control* over the content, then they should have no *liability*
>for it either.  

No, this is not the principle I was getting at.  I was referring to a
principle which was more restricted in its use but which is also
clearer in its interpretation.

This defense is a subset of the defense of no control.  If you can't
read the content, then _a fortiori_ you can't control it either.  It's
really very clear that if you have no basis for distinguishing
communications except for size, time, sender, and recipient, that you
can't act on anything that passes through the system.

>The courts are gradually making that happen.  

This is a good sign.  I heartily approve.  But it is easier to define
legibility with regard to encryption than it is to define control.
Referring to encrypted communications is much less ambiguous and
should be considered a step in the larger direction.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 23 Oct 92 10:33:40 PDT
To: cypherpunks@toad.com
Subject: TEMPEST
In-Reply-To: <9210231704.AA25073@home.merit.edu>
Message-ID: <9210231733.AA11337@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



It should be possible to jam your own emissions, but that same noise
might cause be picked up by your own equipment as well and cause
errors.  Also remember that most of these signals are detected by
correlation, which detects a signal even with a very high S/N ratio.
So it's not obvious just how to jam.  My first guess is to phase-lock
onto your own emmissions and then broadcast random bits at higher
strength.

With E/M monitoring, just like cryptography, you don't really know how
to make defenses unless you know how to attack.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wcs@anchor.ho.att.com (Bill Stewart)
Date: Fri, 23 Oct 92 07:55:30 PDT
To: cypherpunks@toad.com
Subject: Re: Diffie-Hellman
Message-ID: <9210231456.AA20396@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text


Unfortunately, Diffie-Hellman *is* patented, and I'm pretty sure Public Key Partners
(closely related to RSA) holds the patent, just as they hold RSA's.
To quote Steve Bellovin: 
	U.S. Patent Number: 4200770
	Title: Cryptographic Apparatus and Method
	Inventors: Hellman, Diffie, Merkle
	Assignee: Stanford University
	Filed: September 6, 1977
	Granted: April 29, 1980
	[Expires: April 28, 1997]
So we're stuck with it being patented until 1997.
Too bad - I was starting to think along the same lines about doing a D-H-based mailer.
It's non-trivial, if you have to worry about active eavesdroppers swapping
mail messages on you, and it's easier to do if there's a trusted Key Distribution
Center, and if you think about all the cases carefully you tend to re-create
either Needham-Schroeder or the Everhart-Osborn Bell Labs patent (~1980++),
but you can certainly do it for the common case that says the Bad Guys are
only listening to your mail and not tampering with it.

			Bill Stewart, wcs@anchor.ho.att.com
 



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Fri, 23 Oct 92 14:41:59 PDT
To: cypherpunks@toad.com
Subject: multiple message destinations
Message-ID: <9210231806.AA12129@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


Mail typically wants to get sent to multiple receivers, all with
different private keys.  I vaguely recall that the way PGP works is it
generates a symetric cypher key and encrypts the message with that,
then encrypts the generated key with the public key of the intended
receiver.   Is that how it works?

Given that, it should be straightforward (and maybe it already does)
encrypt the generated key with several public keys so you get one
package that can be unsealed by any of several different receivers.

Are there other ways to handle sending to multiple receivers?

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Campbell James A" <UJACAMPBE@memstvx1.memst.edu>
Date: Fri, 23 Oct 92 11:23:11 PDT
To: "cypherpunks" <cypherpunks@toad.com>
Subject: Removal from distribution list
Message-ID: <9210231823.AA08903@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Please remove my address:

                     ujacampbe@memstvx1.memst.edu

                                  from your mailing list.  Thank you.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 23 Oct 92 12:41:02 PDT
To: bill@anubis.network.com
Subject: Keystone
In-Reply-To: <9210222112.AA06121@anubis.network.com>
Message-ID: <9210231827.AA19677@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: bill@anubis.network.com (Bill O'Hanlon)

>>I am very interested in seeing such a protocol standardized because I
>>have another use for it -- secure telephones. Given modern DSPs to do
>>and cheap V.32bis modems, excellent secure voice communications are
>>feasable. The presense of code in the public domain to handle secure
>>encrypted links could be easily dropped right in to this application.
>>

>I've had much the same idea.  There are a lot of people out there with 
>PCs equipped with Soundblasters and V.32 modems.

>I can't think of a better way to fight back against that ridiculous
>FBI Telephone legislation.

Its not quite that simple. The amount of computing horsepower needed
to do a good digitized voice compression algorithm like CELP is way
beyond what a PC can do without a DSP. However, having most of the
link layer encryption stuff out of the way will make the rest of the
work much easier.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 23 Oct 92 12:44:33 PDT
To: gg@well.sf.ca.us
Subject: BBS E-mail policy
In-Reply-To: <199210230930.AA18783@well.sf.ca.us>
Message-ID: <9210231845.AA19935@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: George A. Gleason <gg@well.sf.ca.us>

>Voice: yeah, it's a pain in the tail. One thing I thought might be
>interesting is to use two digitisers: one for the voice input, another for a
>keystream which is derived from a radio or TV program signal which can be
>picked up simultaneously by both correspondents.  XOR the two streams
>together and then do whatever you have to do to make the encrypted results
>transmissable.

Its so simple to just built fully digital systems that use real public
key encryption, I don't see why anyone would want to use something
like you are proposing. Your system would provide virtually no real
security.

I really suggest that anyone who is serious about doing this stuff
read unabridged (hardcover only) version of "The Codebreakers" by
Kahn. He gets into lots of historical examples of how stupidly
designed cryptosystems have cost people their lives. Ususally, people
have very poor ideas of what is and isn't secure. I suggest that some
historical perspective may give people more respect for how hard it is
to do this stuff right.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 23 Oct 92 12:46:25 PDT
To: wcs@anchor.ho.att.com
Subject: Diffie-Hellman
In-Reply-To: <9210231456.AA20396@anchor.ho.att.com>
Message-ID: <9210231904.AA21331@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: wcs@anchor.ho.att.com (Bill Stewart)

>Unfortunately, Diffie-Hellman *is* patented, and I'm pretty sure
>Public Key Partners (closely related to RSA) holds the patent, just
>as they hold RSA's.

>Too bad - 

PGP violates PKPs patents. Everyone is using it. I'm not encouraging
patent violations -- I'm just noting fact.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: jjaloszyns@bluejay.mich.fred.org
Date: Sat, 24 Oct 92 10:01:06 PDT
To: cypherpunks@toad.com
Subject: Re: Keystone
Message-ID: <9210241700.AA13531@home.merit.edu>
MIME-Version: 1.0
Content-Type: text/plain


Speaking of that stupid FBI phone legislation, do you know where I can
obtain an exact copy of the bill?  If you have it, please mail it to me.
thanks...
 
jon

<jjaloszyns@bluejay.mich.fred.org> ------------- 43.31.28N, 84.41.41W 
Jon Jaloszynski
Student 9-12 at Shepherd HS,  Shepherd                     Shepherd, MI





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 23 Oct 92 23:20:44 PDT
To: cypherpunks@toad.com
Subject: entropy measures
In-Reply-To: <9210231641.AA11868@xanadu.xanadu.com>
Message-ID: <9210240620.AA08036@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Dean:
>Where does uuencoded [compressed] binary lie?  I would suspect it lies
>right around where encrypted text is.  

Right.

>Presumably straight encrypted
>text is statistically random [7..8], but that when you encrypt to
>just the ascii subset is when you lose the entropy.

Exactly.

uuencoding will have a slightly lower single-character entropy than
the ASCII armor PGP uses because just about every line begins with the
letter 'M'.  This will skew the distribution slightly.  But a better
way of distinguishing uuencoding and ascii armor is to see that in
falls in the same entropy class, and then just looking at the
alphabetic subsets used.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 23 Oct 92 23:27:22 PDT
To: cypherpunks@toad.com
Subject: multiple message destinations
In-Reply-To: <9210231806.AA12129@xanadu.xanadu.com>
Message-ID: <9210240626.AA08212@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Dean:
>Are there other ways to handle sending to multiple receivers?

1) You can send it to a service which copies the message and resends
it as many times as you need.  Or send it yourself.

2) You can have the multiple recipients each share a key and let them
trust each other.  (Not recommended for the paranoid).

3) You can use a secret sharing system which is tied to a private key,
such that revealing the secret allows for the derivation of the
private key.  The secret itself is a different private key.  (I'm not
up on the details of these schemes.)

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Sat, 24 Oct 92 02:31:19 PDT
To: uunet!soda.berkeley.edu!hughes@uunet.UU.NET
Subject: multiple message destinations
In-Reply-To: <9210240626.AA08212@soda.berkeley.edu>
Message-ID: <9210240854.AA15621@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


Doies the scheme I suggested (and I'm sure is not original) work?
Using all the various private keys to encrypt a single cypher key that
the rest of the message is encrypted with?

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sat, 24 Oct 92 09:24:30 PDT
To: xanadu!tribble@uunet.UU.NET
Subject: multiple message destinations
In-Reply-To: <9210240854.AA15621@xanadu.xanadu.com>
Message-ID: <9210241624.AA12449@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: multiple encryptions of a message key.

Yes, it works.  Sorry.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 24 Oct 92 09:02:41 PDT
To: <cypherpunks@toad.com>
Subject: Multiple messages + entropy
Message-ID: <921024155350_74076.1041_DHJ67-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


The Internet PEM (Privacy Enhanced Mail) standard uses the
concept which Dean Tribble mentioned of multiple encryption
(using each recipient's public key) of a single session key
which encrypts the message.  PGP's data structures do not
currently provide for this but could be extended pretty easily
to allow it.

On the entropy measure - I thought entropy was how many bits
of information you get per character.  Encrypted binary text
would be pretty close to 8 bits per character.  The RFC1113
Ascii encoding used by PGP reduces this to 6 bits per character
(e.g. a character set with 64 printable characters) neglecting
line separators and message beginnings and endings.  So there
should be a little less than 6 bits per character for encrypted,
Ascii-encoded messages.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fen@netcom.com (Fen Labalme)
Date: Sat, 24 Oct 92 13:09:09 PDT
To: jjaloszyns@bluejay.mich.fred.org
Subject: ftp.eff.org:/pub/EFF/legislation/new-fbi-wiretap-bill
Message-ID: <9210242007.AA14367@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


The following is the latest version of the FBI Digital Telephony 
Proposal, introduced in May 1992. This version removes the previous 
language that authorized the FCC to set standards and now places it 
solely in the hands of the Attorney General. Fines are $10,000/day for 
non compliance with services within the public switched network having 
18 months to comply and services outisde having three years.  The 
proposal now manadates that the capability for remote government 
wiretapping must be included into the system.

This proposal clearly enhances the ability of the FBI to monitor 
communications.  It takes the unprecendented step of placing control 
over certification of telecommunications equipment in the hands of the 
Attorney General and requires that the equipment be constucted to allow 
government have the ability to monitor communications from a 
"government monitoring facility remote from the target facility."  All 
telecommunications users should be concerned by the privacy and 
security implications of creating systems that have holes for the 
government or any other knowledgable user to plug into.


102nd Congress
    2nd Session

                              S. _____
                           [H.R. _____]

                         IN THE SENATE
             [IN THE HOUSE OF REPRESENTATIVES]


M. ________________ introduced the following bill;  which was
referred to the Committee on__________________


A BILL


To ensure the continuing access of law enforcement to the content of 
wire and electronic communications when authorized by law and for other 
purposes.

Be it enacted by the Senate and the House of Representatives of the 
United States of America in Congress assembled,


SEC. 1.  FINDINGS AND PURPOSES.
     (a)  The Congress finds:
    (1)  that telecommunications systems and networks are often used in 
the furtherance of criminal activities including organized crime, 
racketeering, extortion, kidnapping, espionage, terrorism, and 
trafficking in illegal drugs;
    (2)  that recent and continuing advances in telecommunications 
technology, and the introduction of new technologies and transmission 
modes by the telecommunications industry, have made it increasingly 
difficult for government agencies to implement lawful orders or 
authorizations to intercept wire and electronic communications and thus 
threaten the ability of such agencies effectively to enforce the laws 
and protect the national security;  and
     (3)  that without the assistance and cooperation of providers of  
electronic communication services and private branch exchange 
operators, the introduction of new technologies and transmission modes 
into telecommunications systems without consideration and accommodation 
of the need of government agencies lawfully to intercept wire and 
electronic communications would impede the ability of such agencies 
effectively to carry out their responsibilities.
     (b)  The purposes of this Act are to clarify the responsibilities 
of providers of electronic communication services and private branch 
exchange operators to provide such assistance as necessary to ensure 
the ability of government agencies to implement lawful court orders or 
authorizations to intercept wire and electronic communications. 

SEC. 2. 
      (a)  Providers of electronic communication services and private 
branch exchange operators shall provide within the United States 
capability and capacity for the government to intercept wire and 
electronic communications when authorized by law:  
     (1)  concurrent with the transmission of the communication to the 
recipient of the communication;
     (2)  in the signal form representing the content of the 
communication between the subject of the intercept and any individual 
with whom the subject is communicating, exclusive of any other signal 
representing the content of the communication between any other 
subscribers or users of the electronic communication services provider 
or private branch exchange operator, and including information on the 
individual calls (including origin, destination and other call set-up 
information), and services, systems, and features used by the subject 
of the interception;
     (3)  notwithstanding the mobility of the subject of the intercept 
or the use by the subject of the intercept of any features of the 
telecommunication system, including, but not limited to, speed- dialing 
or call forwarding features;
     (4)  at a government monitoring facility remote from the target 
facility and remote from the system of the electronic communication 
services provider or private branch exchange operator;
     (5)  without detection by the subject of the intercept or any 
subscriber;  and
     (6)  without degradation of any subscriber's telecommunications 
service.
     (b)  Providers of electronic communication services within the 
public switched network, including local exchange carriers, cellular 
service providers, and interexchange carriers, shall comply with 
subsection (a) of this section within eighteen months from the date of 
enactment of this subsection.
     (c)  Providers of electronic communication services outside of the 
public switched network, including private branch exchange operators, 
shall comply with subsection (a) of this section within three years 
>from the date of enactment of the subsection.
     (d)  The Attorney General, after consultation with the Department 
of Commerce, the Small Business Administration and Federal 
Communications Commission, as appropriate, may except from the 
application of subsections (a), (b) and (c) of this section classes and 
types of providers of electronic communication services and private 
branch exchange operators.  The Attorney General may waive the 
application of subsections (a), (b) and (c) of this section at the 
request of any provider of electronic communication services or private 
branch exchange operator.
     (e)  The Attorney General shall have exclusive authority to 
enforce the provisions of subsections (a), (b) and (c) of this section.  
The Attorney General may apply to the appropriate United States 
District Court for an order restraining or enjoining any violation of 
subsection (a), (b) or (c) of this section.  The District Court shall 
have jurisdiction to restrain and enjoin violations of subsections (a) 
of this section.
     (f)  Any person who willfully violates any provision of subsection 
(a) of this section shall be subject to a civil penalty of $10,000 per 
day for each day in violation.  The Attorney General may file a civil 
action in the appropriate United States District Court to collect, and 
the United States District Courts shall have jurisdiction to impose, 
such fines.
     (g)  Definitions--As used in subsections (a) through (f) of this 
section--
     (1)  'provider of electronic communication service' or 'private 
branch exchange operator' means any service or operator which provides 
to users thereof the ability to send or receive wire or electronic 
communication, as those terms are defined in subsections 2510(1) and 
2510(12) of Title 18, United States code, respectively, but does not 
include the government of the United States or any agency thereof;
     (2)  'communication' means any wire or electronic communication, 
as defined in subsections 2510(1) and 2510(12), of Title 18, United 
States Code;
     (3)  'intercept' shall have the same meaning as set forth in 
section 2510(4) of Title 18, United States Code;  and
     (4)  'government' means the Government of the United States and 
any agency or instrumentality thereof, any state or political 
subdivision thereof, the District of Columbia, and any commonwealth, 
territory or possession of the United States.      

DIGITAL TELEPHONY AND INTERCEPTION BY CRIMINAL LAW ENFORCEMENT AGENCIES 
    The telecommunications systems and networks are often used to 
further criminal activities including white collar and organized crime, 
racketeering, extortion, kidnapping, espionage, terrorism, and 
trafficking in illegal drugs.  Accordingly, for many years, one of the 
most important tools in the investigation of crime for Federal and 
State criminal law enforcement agencies has been the court authorized 
interception of communications.  As illustrated below, the majority of 
original authorizations to intercept wire or electronic communications 
are conducted by State criminal law enforcement agencies. 

   Interception Applications Authorized
      State  Federal  Total 
1984    512    289    801 
1985    541    243    784 
1986    504    250    754 
1987    437    236    673 
1988    445    293    738 
1989    453    310    763 
1990    548    324    872 
Total  3440   1945   5385

   Approximately, 3/8 of authorized interceptions were conducted by 
Federal agencies, while 5/8 of the authorized interceptions were 
conducted by State criminal law enforcement agencies.1 
    The recent and continuing advances in telecommunications 
technology, and the introduction of new technologies by the 
telecommunications industry, have made it increasingly difficult for 
government agencies to implement lawful orders or authorizations to 
intercept wire and electronic communications, as well as to implement 
pen register and trap-and-trace court orders or authorizations.  These 
new technologies inadvertently undermine the ability of criminal law 
enforcement agencies to enforce effectively the criminal laws and 
protect the national security.  Without the assistance and cooperation 
of the telecommunications industry, these new technologies will impede 
the ability of the telecommunications industry, these new technologies 
will impede the ability of the government to enforce the criminal law. 
Accordingly, the purpose of this bill is to clarify the existing 
responsibilities of electronic communication services providers and 
private branch exchange operators, as established, for example, in 18 
U.S.C. ____ 2518(4), 3124(A), (B), to provide such assistance as 
necessary to ensure the ability of government agencies to implement  
lawful orders or authorizations to intercept communications. 
    Over the past twenty-five years, the working relationship between 
the criminal law enforcement community, particularly the Federal Bureau 
of Investigation as the federal government's primary criminal law 
enforcement agency, and the telecommunications industry, in response to 
the appropriate court orders or authorizations, has provided government 
agencies with timely access to the signals containing the content of 
communications covered by the court orders or authorizations.  As a 
general proposition, this has involved providing the means to acquire 
the communication as it occurs between two individual telephone users 
at a remote location, not dissimilar to a call in which the two 
originating parties do not know that a third party is listening, and in 
which the third party (the criminal law enforcement agency) records the 
authorized and relevant calls. 
    Historically, and with relatively few exceptions, the 
telecommunications industry has provided the criminal law enforcement 
community with the ability to monitor and record calls:

   1.  at the same time asthe call is transmitted to  the recipient;

   2.  in the same form as the content of the call was transmitted 
through the network, notwithstanding the use by the target of custom  
features of the network; 

   3.  whether stationary or mobile;

   4.  at the government monitoring facility; 

   5.  without detection by the target or other subscribers; and 
without degrading any subscriber's service.

    However, the introduction of new technology has begun to erode the 
ability of the government to fully effectuate interceptions, pen 
registers and trap-and-race court orders or authorizations that are 
critical to detecting and prosecuting criminals.  As technology has 
developed, the telecommunications industry has not always ensured the 
continued ability to provide the same services to the criminal law 
enforcement community.  The telecommunications industry's introduction 
of certain types of new technology poses real problems for effective 
criminal law enforcement.  Legislation is necessary to ensure that the 
government will be provided with this capability and capacity in the 
future by all providers and operators and to maintain a level playing 
field among competitive providers and operators in the 
telecommunications industry.

   There have been instances in which court orders authorizing the 
interception of communications have not been fulfilled because of 
technical limitations within particular telecommunications networks.  
For example, as early as 1986, limited capabilities became apparent in 
at least one network which will only be corrected later in 1992.  This 
technical deficiency in a new technology forced criminal law 
enforcement agencies to prioritize certain interceptions to the 
exclusion of other court orders. Accordingly, for approximately six 
years, there have been court orders that have not been sought by the 
criminal law enforcement community or executed by the 
telecommunications industry and, as a consequence, important criminal 
investigations have not been brought to fruition or have been less than 
efficiently concluded.  This is one classic example of new technology 
affecting adversely the criminal law enforcement community:  a 
microcosm of what may be expected on a nationwide basis without 
enactment of this legislation. 
     Section 1 of the bill states Congressional findings and purpose. 
     Section 2 is divided into seven subsections..  Subsection (a) 
establishes as a matter of law the responsibility of electronic 
communication services providers and private branch exchange operators 
to continue to provide, within the United States, the capability and 
capacity for criminal law enforcement agencies to intercept wire and 
electronic communications when authorized by law.  These subsections 
delineate the existing attributes of wire or electronic communication 
interception. 
    1. Concurrent with Transmission.  The application for a court order 
to intercept telecommunications conversations or data transmissions is 
rarely a leisurely process.  For example, on the Federal side, the 
development of the required affidavits, submission to the Criminal 
Division of the Department of Justice for approval, transmission of 
approval to the Assistant United States Attorney, the appearance of the 
Assistant before a judge to request the order and the delivery of the 
judge's order to the appropriate telecommunications company is 
frequently completed in a very short time.  However, crime waits for no 
one and the system for approval of interceptions must and does conform 
with the realities of the activity that is sought to be investigated 
and, if appropriate, prosecuted as criminal offenses.  Since time is of 
the essence, current law requires that service providers and operators 
provide the government forthwith all information, facilities and 
technical assistance necessary to accomplish its mission.  It is 
critical that the telecommunications industry respond quickly to 
execute the court order or authorization.  The ultimate problem of 
timeliness, however, is the real-time monitoring of the intercepted 
communications.  As serious and potentially life- threatening criminal 
conduct is detected, it may be necessary to move quickly to protect 
innocent victims from that conduct.  Accordingly, "real-time" 
monitoring is critical. 
     2. Isolated Signal and Services Used. Nearly all of the  
communications network is partially "analog" at this time.  In 
conducting an interception, for example, of a telephone conversation, 
the government is allowed to monitor and record criminal conversation 
such as a conspiracy, minimizing the acquisition of non-criminal or 
innocent conversation.  When an electronic communication services 
provider or private branch exchange operator introduces a new 
technology--such as a digital signal--the communications are converted 
into a different and more efficient form for transmission, but a more 
difficult form to monitor during interception.  The bill requires only 
that the provider or operator isolate and provide access to the 
electronic signal that represents the content of the communications of 
the target of the intercept2  from the stream of electronic signals 
representing other communications.  This provision seeks to ensure 
that, in the new electronic environment in which signals are mixed for 
transmission and separated at another switch for distribution, the 
government does not receive the communications of any individual other 
than the individuals using the target's communications point of origin 
and receipt;  the government must remain subject to the minimization 
standards of 18 U.S.C. __  2518(5). 
     This provision also makes it clear that an electronic 
communication services provider or private branch exchange operator is 
not required to provide for reconversion of the isolated communication 
to analog or other form.  The government expects that this process will 
be accomplished by the government. 
     3. Mobility and Features.  Increasingly, criminal acts are being 
conducted or discussed over cellular telephones or by using special 
telecommunications features.  As this mobility is introduced, the 
electronic communication services providers and private branch exchange 
operators would be required to assure the capability and capacity for 
criminal law enforcement agencies to continue lawful interception. 
     Further, this subsection makes it clear that features used by the 
target do not defeat the court order or authorization.  For example, 
communications which have been addressed to the telephone number of the 
target, but which may have been programmed through a call-forwarding 
feature to another, otherwise innocent, telephone number, must be 
captured and made available to criminal law enforcement authorities 
pursuant to court order or authorization.  This requirement will 
obviate the need for applications for authority to monitor otherwise 
innocent telephone numbers that receive, only intermittently, calls 
forwarded by the target.  The effect of this provision is to further 
minimize monitoring of calls of innocent parties.  Similarly, certain 
speed dialing features that mask the telephone number called by the 
target must be identified for criminal law enforcement investigation.  
The ability to consistently determine the destination of calls is 
critical to minimizing the monitoring of innocent calls. 
     4. Government Monitoring Facility. Government agencies do not 
normally request the use of telecommunications industry physical 
facilities to conduct authorized interceptions nor is it encourage by 
the industry.  Normally, the government leases a line from the 
electronic communication services provider's or private branch exchange 
operator's switch to another location owned or operated by the 
government.  This minimizes the cost and intrusiveness of 
interceptions, which benefits the service provider or operator, as well 
as the government.  Accordingly, the ability to monitor intercepted 
communications remotely is critical. 
     5. Without Detection.  One of the reasons that governments operate 
their own facilities is to reduce the risk of detection of the 
interception, which would render the interception worthless.  At the 
present time, the existence of an interception is unknown to any 
subscriber and is not detectable by the target, notwithstanding 
folklore and spy novels.  This provision merely ensures that the 
secrecy of effective interceptions will be maintained. 
     6. Without Degradation.  Maintaining  the quality of the telephone 
network is in the interest of the government, the industry and the 
public.  Presently, the existence of an interception has no effect on 
the quality of the service provided by any network to the target or any 
subscriber.  This provision ensures that the quality of the network 
will continue to be uncompromised.  Absent the assistance delineated by 
this legislation, the execution of court orders and authorizations by 
the government could well disrupt service of the newer technological 
systems, a result that this legislation seeks to avoid. 
     Subsection (b) provides that electronic communication services 
providers and private branch exchange operators with the "public 
switched network" must be in compliance with the minimum intercept 
attributes within eighteen months after enactment.  Thereafter, new 
technologies must continue to meet these minimum attributes. 
     Subsection (c) provides that electronic communication service 
providers and private branch exchange operators that are not within the 
"public switched network" must be in compliance with the minimum 
intercept attributes within eighteen months after enactment. 
Thereafter, new technologies must continue to meet these minimum 
attributes. 
     Subsection (d) provides that the Attorney General may grant 
exceptions to the affirmative requirements of subsection (a), as well 
as the implementation deadlines of subsections (b) and (c).  In 
considering any request for exception, the Attorney General will 
consult with Federal Communications Commission, the Small Business 
Administration and the Department of Commerce, as appropriate.  
Accordingly, the Attorney General has the authority to except, for 
example, whole classes, categories or types of private branch exchange 
operators where no serious criminal law enforcement problems are likely 
to arise, such as hospital telephone systems. 
     This subsection also permits the Attorney General to waive the 
requirements of subsections (a), (b) and (c) on application by an 
electronic communication services provider or private branch exchange 
operator. Accordingly, if a particular company can not comply with one 
or more of the requirements of subsection (a), or needs time additional 
to that permitted under subsections (b) or (c), the Attorney General 
may grant an appropriate waiver. 
     Subsection (e) provides that the Attorney General has exclusive 
authority to enforce the provisions of the bill.  While a number of 
States have authority to seek and execute interception orders, they 
will be required to seek the assistance of the Attorney General if 
enforcement of this legislation is required.  This section also 
provides for injunctive relief from violations of the provisions of the 
bill. 
     Subsection (f) provides for enforcement of the provisions of the 
bill through imposition of civil fines against any company that is not 
excepted from the provisions of the bill, does not acquire a waiver of 
the provisions of the bill, and fails to meet the requirements of 
subsection (a) after the effective dates set out in subsection (b) or 
(c), as appropriate.  A fine of up to $10,000 per day for each day in 
violation may be levied;  for most companies in the telecommunications 
industry this amount is sufficient to ensure that compliance will be 
forthcoming.  Although this provision is not expected to be used, it is 
critical to ensure that compliance with the provisions of the bill will 
occur after the effective dates of the requirements of subsection (a). 
     Subsection (g) carries forward a number of definitions from the 
current provisions for the interception of wire or electronic 
communications under "Title III."  The definition of "government" that 
is currently in use includes all States, territories and possessions of 
the United States, as well as the United States, is made applicable to 
the bill.

   [Footnotes]  1Interceptions for foreign intelligence and 
counterintelligence purposes are not counted within the figures used 
here, but would likewise benefit from enactment of the legislation.

   2 Whether the content is voice, facsimile, imagery (e.g. video), 
computer data, signalling information, or other forms of communication, 
does not matter; all forms of communication are intercepted. 
 








From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fen@netcom.com (Fen Labalme)
Date: Sat, 24 Oct 92 13:24:14 PDT
To: jjaloszyns@bluejay.mich.fred.org
Subject: Re: fbi-wiretap-bill (& ftp.eff.org)
Message-ID: <9210242023.AA15395@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


>> Speaking of that stupid FBI phone legislation, do you know where I can
>> obtain an exact copy of the bill?  If you have it, please mail it to me.

Mail sent.

Also, a pointer to ftp.eff.org is worthwhile to note.
I just grabbed a new copy of the bill from there, under /pub/EFF/.
Below are some file listings from their archives.  Enjoy!

Yours in networking,
Fen Labalme

fen@genmagic.com           fen@netcom.com                   Just say "Know!"
General Magic              Broadcatch Technologies          We Are Everywhere

    Member of the League for Programming Freedom <league@prep.ai.mit.edu>,
              the Electronic Frontier Foundation <eff@eff.org>, and the
Computer Professionals for Social Responsibility <cpsr-staff@csli.stanford.edu>


ftp> cd pub/EFF
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
eff-issues
legislation
about-eff
Index
mission-statement
legal-issues
.message
about-eff.ps
papers
local-chapters
historical
newsletters
newsnotes
226 Transfer complete.
160 bytes received in 0.012 seconds (13 Kbytes/s)
ftp> cd legal-issues
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
bbs-defamation
privacy-vs-amendments
Index
copyright-law-software
copyright-libraries
bill-of-rights-overview
ecpa-laymans-view
email-privacy-biblio-2
media-and-law
email-privacy-research
search-seizure-files
review-liability
tempest-legal-issues
bbs-and-the-law
against-look-and-feel
computer-security-intro
cyberspace-legal-matrix
electrifying-speech
eff-fbi-analysis
private-open-society
226 Transfer complete.
411 bytes received in 0.038 seconds (11 Kbytes/s)
ftp> cd ../legislation
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
ecpa-1986
Index
computer-crime-laws
fbi-wiretap-bill
telecom-act-hr3515
ecpa-1986-senate-bill
tribe-proposed-amendment
nren-bill-text
gpo-windo-info
privacy-act-1992-calif
gore-infrastructure-bill
new-fbi-wiretap-bill
226 Transfer complete.
230 bytes received in 0.024 seconds (9.3 Kbytes/s)
ftp>




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: deckard@chezrob.pinetree.org (Stephen Pandke)
Date: Sat, 24 Oct 92 14:49:54 PDT
To: cypherpunks@toad.com
Subject: Removal From Mailing list
Message-ID: <cy26sB1w165w@chezrob.pinetree.org>
MIME-Version: 1.0
Content-Type: text/plain


Unfortunately, I must request that I be removed from your
mailing list.  ]

Stephen Pandke

---
 Stephen Pandke   -   deckard@chezrob.pinetree.org
 C.R.I.M.E. BBS - (Chez Rob's Int'l Mail Exchange) 613/230-5307 (data)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: shawnb <shawnb@ecst.csuchico.edu>
Date: Sat, 24 Oct 92 20:33:12 PDT
To: cypherpunks@toad.com
Subject: pgp key distribution
Message-ID: <9210250333.AA11925@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


I'm pretty new to this mailing list, so something along these lines may
have already been proposed, but I was considering the possibility of
putting together a list of pgp public keys for distribution through this
list.  My own collection of keys is pretty small, and I would pernally 
like to expand this, but I think this would provide a great service to the
group as well.  Let me know what you all think.

Shawn




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: David Cabana (MTH) <drcc@ultrix.csc.usf.edu.>
Date: Sat, 24 Oct 92 17:43:41 PDT
To: cypherpunks@toad.com
Subject: pgp
Message-ID: <9210250037.AA19290@ultrix.csc.usf.edu.>
MIME-Version: 1.0
Content-Type: text/plain


Where in the U.S. can I ftp a copy of PGP?   I tried Kauri.vuw.ac.nz,
but their README asked that I not transfer files.   I would like to 
respect their wishes...
		Thanks,
		drc




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Sat, 24 Oct 92 20:54:34 PDT
To: shawnb <shawnb@ecst.csuchico.edu>
Subject: Re: pgp key distribution
In-Reply-To: <9210250333.AA11925@toad.com>
Message-ID: <9210250354.AA00857@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



jyanowitz@hamp.hampshire.edu is already creating a list 
(you can find it posted to alt.security.pgp).  As for me
I maintain two public rings one is a collection I have collected via
direct contact (friends mostly) the other is jyanowitz's list plus
random other rings).


		    -Pete

Ps: I do not know jyanowitz (etc etc, but while we are on the subject)
    but I guess I should relay his request for people to email him your
    keys and public rings
    

my casual key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx
gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptAZjYXN1
YWy0JlBldGVyIE0gU2hpcGxleSA8c2hpcGxleUBiZXJrZWxleS5lZHU+
=OR9u
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: joeb@arden.linet.org
Date: Sat, 24 Oct 92 21:11:19 PDT
To: cypherpunks@toad.com
Subject: remove from mailing list
Message-ID: <9210242237.aa22143@src4src.linet.org>
MIME-Version: 1.0
Content-Type: text/plain


Please unsubscribe me from your list.  The mail load is just too much.

I noticed that there are alot of people that subscribe then unsubscribe.  You
may want to consider mentioning in your ads the nature of this forum.  I
assumed it was a periodical newsletter of some kind.  I would speculate from
the frequency of subscribers that quickly un-subscribe that many are under the
same assumption.

This topic is very interesting but the mail is just too much.  If you guys
come out with a newsletter of some kind I'd be very interested.

Thanks and sorry for the extra work.

- JoeB





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Sat, 24 Oct 92 19:34:56 PDT
To: tribble@xanadu.com
Subject: multiple message destinations
In-Reply-To: <9210231806.AA12129@xanadu.xanadu.com>
Message-ID: <9210250201.AA07719@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: tribble@xanadu.com (E. Dean Tribble)

>Mail typically wants to get sent to multiple receivers, all with
>different private keys.  I vaguely recall that the way PGP works is it
>generates a symetric cypher key and encrypts the message with that,
>then encrypts the generated key with the public key of the intended
>receiver.   Is that how it works?

>Given that, it should be straightforward (and maybe it already does)
>encrypt the generated key with several public keys so you get one
>package that can be unsealed by any of several different receivers.

Yes, that should work. PGP doesn't do it, but it would be
straightforward to change it so it could.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Sat, 24 Oct 92 22:03:00 PDT
To: shawnb@ecst.csuchico.edu
Subject: pgp key distribution
In-Reply-To: <9210250333.AA11925@toad.com>
Message-ID: <9210250427.AA08570@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: shawnb <shawnb@ecst.csuchico.edu>

>I'm pretty new to this mailing list, so something along these lines may
>have already been proposed, but I was considering the possibility of
>putting together a list of pgp public keys for distribution through this
>list.  My own collection of keys is pretty small, and I would pernally 
>like to expand this, but I think this would provide a great service to the
>group as well.  Let me know what you all think.

I keep seeing people propose things like this, and I can't for the
life of me understand why. The only way to know for sure that
someone's key is theirs is a signature from a trusted introducer
anyway, so people can just ask each other in clear for public keys and
it doesn't do a lick of harm -- if they have a trusted signature, you
can use their key for communication and if they don't, you have to
find another way to verify the key.  People making lists of keys and
distributing them seems fairly useless to me. Can anyone tell me if I
am being really really thick here?

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 24 Oct 92 21:47:19 PDT
To: <CYPHERPUNKS@TOAD.COM>
Subject: Re: remove from mailing list
Message-ID: <921025044014_74076.1041_DHJ64-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


What we _ought_ to do is to remind people that they should send
their unsubscribe notices to cyherpunks-request@toad.com, _not_
to the list address.  That way we wouldn't all have to be bothered
by reading these messages, and the list volume would be that much
lower!





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sun, 25 Oct 92 12:08:31 PPE
To: cypherpunks@toad.com
Subject: re: multiple message destinations
Message-ID: <3266.2AEAF026@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain




 U> 1) [...]  Or send it yourself. 

As a paranoid person myself (I use the two phrases "sufficiently
paranoid" (me, and most of us in here are sufficiently paranoid -- to
at least consider the issues) and "insufficiently paranoid" -- people
who conduct business over cordless or cellular voice, etc -- these
paren'd subtexts are getting out of hand -- as a paranoid person
myself I would only trust sending them myself.

It's really a "code" issue -- given a list of addressees, will the
miserable program you're using do the work for you.


--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sun, 25 Oct 92 13:08:17 PPE
To: cypherpunks@toad.com
Subject: re: pgp key distribution
Message-ID: <3269.2AEAFD72@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain




 U> From: shawnb@ecst.csuchico.edu (shawnb)
 U> I'm pretty new to this mailing list, so something along 
 U> these lines may have already been proposed, but I was 
 U> considering the possibility of putting together a list of 
 U> pgp public keys for distribution through this list.  My 

The FidoNet has an echo ("newsgroup") where each message ("article")
is someones public key.

Here's my keyring, for what it's worth:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAirSicsAAAEEALQ8l1jjbcASxKkdlHACfaE+em9i996Sos8ox50JjhZNu9N6
mft8V0App0eXTYAEumnz+CVVJXjzMUgloGs1ZnyvqkT3VhaF6CyUSUFwXIym/IUk
buvs3qqEU55yGTl1s2gcjgiqyL/1jmOIdaaMQNrQ4/4x28gaOFQYMJXaJ+w1AAUR
tC5XZXMgUGVya2hpc2VyIDx3ZXMucGVya2hpc2VyQHdlaXNlLm9tYWh1Zy5vcmc+
iQCVAgUQKtRrakq2SryVeKUXAQGF4AP+JDQawppDmAteShKF6Be24MGpByxYnIYR
XyHpKOIcGx45S7FZOoS+mGzU4VXRYF9reHvfYGnz0GGjZ962K5tFJSSupF7ccxBi
nLA3EYltX8iIufbyLwoS6Bb2gmX6Z5kfDVcffvlw8RqWFAwxows6QU8VvadLa40B
mEjvVqzAIgiZAI0CKuQvgAAAAQQA0CiZieU9eimeaz1G1TSWf0KIsmWOyw55+UL0
D5AgO6NeE9PIClsvpU+pJRKgUX97vbFMmLHKvAFCHDmUC9+9A8SIYgVBBjG+IX5C
D/7r8lW8sKO+cZUWX2QpMRhV443EE0aJpe5ITRUxAvHjuI/0BT7BjDrZpeZM21bU
FS1fkEcABRG0MEphbWVzIEEuIENhbXBiZWxsIDx1amFjYW1wYmVAbWVtc3R2eDEu
bWVtc3QuZWR1PpkAjQIq43aAAAABBACqyZ7OXOK217FIvtParcy1nOgZUcLqrapK
Fq0nefdbEHLiaB+i1jeTdSoUqehMi3+ZiDICDxuVF6yBqCDsrl3tOd8mLC3Pe6Bk
W4gCi6KI2XrIpb1DCKc4EscjzWSku2E0lYiLAfkh4BTwzxcbTr6Yj9CJjVb1JJ46
YDMOhX+YvQAFE7QrRGFyaW4gQ293YW4gPGNvd2FuQGNlcmlhbnRodXMucGluZXRy
ZWUub3JnPpkAjQIq4AX1AAABBADPMVf0NZ/LoWxUJXf+a3dTG0xIHW+FCfKbn5os
9ZLwQTV/tloYGolyVSEqIjS7EgxtoFfiqzJyMkN5o4ctxCXs/xcBKfwiib6ffLPn
cz5hNInkylhUu6b9K0ZDV5kfzdoeTR2H8SDT2e3vn/GOlCGosOzJS2crKfwnisK+
iFySIQAFEbQJVGVkIFJvbGxltBMyMDEwOjEwMC8xLjBAU0RBbmV0tBIxOjEwNS8z
Ni4wQGZpZG9uZXSZAI0CKtfw+gAAAQQAxHc5YohUHjHM3UGj91c39vsntGzR/8cH
+m0RokT7/F/F3zXNdLTumHlD92OK4hdAPWEp+xVAygyKKDp+LBFI4JTPhx2iNELm
yum5SusJMf1FW+2m6zIK/0gzMqgd2QDb6GsMsFqxlDctnIrz9uqZCJuD3LfHjucw
9RbQfSEuxUsABRe0Okd1eSBNYXJ0aW4gMToxNDMvMjY5IChndXkubWFydGluQGYy
NjkubjE0My56MS5maWRvbmV0Lm9yZymZAI0CKtXkPgAAAQQA2srhlr3MEdQ+rcQv
atnLX5mhZavCVuyc44Ezhn1EG/kd0vafg93Y5EJTplPryrPeABmuC72RhJ2kdEnZ
nsAxO+SkJzX3/FlnVyatu7VVosR2Wcl5pLQMhaYz0ZhRRoIv1GIqAnMmcD/SbBFD
puSkzTD4Mjn7TPHJo6l60efyPZUABRG0J01pa2UgTGFzdGVyIDxsYXN0ZXJtQG9o
bS5lZS51dHVsc2EuZWR1PrQfTWlrZSBMYXN0ZXIgPDE6MTcwLzEwOUBmaWRvbmV0
PpkAjQIq3Pf5AAABBADTqwU2BaFR8+VElyuQ7VXkGn2IcVPZYxH1pqTRI7G+HTnB
iaZl2dT24CkSD5uO7TPAPxFl0A1hDzt03cv3SMdIkfbAxWzI1dwno0+Wy5z84puf
tYPjaXA08Dc1L8pAiZzDYtx95NBCKqirjbTFuOl7BUB2HYpjv+K+Xqpu25EANwAF
EbQxQmFycnkgS2Fwa2UgPEJhcnJ5LkthcGtlQGYzMy5uMTI1LnoxLmZpZG9uZXQu
b3JnPpkAjQIqwncSAAABBACvXC8GUY83UrGJPzD2CG098ZiWfu9yMTPKz2ji+TK4
e0KI5M13DWa+1bWPm+WWv0dYnJrKSmQ7sYbKK3owd/byvNIYC6QfN2Nl0C8RcNk4
lduLlOlEWXzQuLKPaZhqx9uahtibSnHmf705lDnXN4ijPAd5ooc30tf/+yHKJrNc
0wAFE7QtSmFzb24gWWFub3dpdHogPGp5YW5vd2l0ekBoYW1wLmhhbXBzaGlyZS5l
ZHU+iQCVAgUQKtBLM//7Icoms1zTAQFkqQQAndM0KgNy0hBQEI7QUrxMBE1nNzvg
5hpoqBO0nCmlckhzB1JZfUATCU9zkNyZ9VifFuGSnoj1HgPYl4lEDOtASZm8MUup
bSb1T1JMdkM6C50t9WjPl6LIj0tldHLGefDqpOTantqCdyz8WuRqUJ7S/JKPTNQ0
t5LidT1o4s3/M42ZAE0CKtrZngAAAQIA9UJPv2NsjfiajySZ3ihHPNNUA3J+pBke
dcQ6JVpsB1/BS1NVx8KGKivpPXgFtYvtR4oBEZEVlLCZWKoJnH6ZvQAFEbQiUmlj
aCBWZXJhYSA8MToxMzUvOTA3QGZpZG9uZXQub3JnPokAlQIFECrchQltbThSc0ua
WQEB4uIEAKN+Cl7wUI/1tFckEfZc7WDbsN8F3wP+mZVanZOeQi8KlViSsatQ7D9E
1LfjNo/03BE7vDODpm3l/RHhQLwfDkMuS49EBDF0qhIn45X4v6ImUrF4Fs1MRPQE
10lnoWQs2CjStPmSWhG2jvL7xMPSy1r8m4n6dxGcyxCFML8ckyU8mQCNAiraG3wA
AAEEAJuaF6NRnKvVEU3edX8OUxMdb+k3ZRfd2KM3b7+7mahkMqTfKj/wiNpqbnnV
/pKoD3jf35KjO0i+Oa5spGCc3I7VCDDcKhHV6iZcYD0lpF2ySh5sUFsRGqWO4oo/
jyzrNgzV0awrg2IYT5u7ClLXbpuZGcdIKbTNdZuaN9X1csanAAUTtDFKaW0gQ2Fu
bmVsbCA8SmltLkNhbm5lbGxAZjIxLm4yMTYuejEuZmlkb25ldC5vcmc+iQCVAgUQ
KtpDRG1tOFJzS5pZAQHn0wP+LkupLVZYBbGPfXdkHaCxwRWEc5xBfIRO2SwpJZBB
HclFuu0OxxOuilc6bAiswbPHoMSP0MnOChOa+g0BFxhRjfKVXiXhP2Oo1lqAZ41r
7E9h4oYs4YYo7fjM1lZZtezWNKIibuW57lhdyvLMbDx6oxCP55AG7zTWRzL0DQnY
sjOZAI0CKtHW8wAAAQQApMSslBzYEUQzIER/SRu3xXTdruTE0EQ4CZfa9ZNhVbTx
e6joVfUzLTSno6iwzjEJgSeL/yPIukK3hH2whUXLD87dcR+dhSuuK7ans2owRo+c
CfH3zKTyMleHZEAVoTSOaDPVVUfUaDpukr0ujXMBa8DAIuoJrsKPiJ6a6GXD6cEA
BRe0JkppbSBHcnVicywgVzhHUlQgPDE6MjM0LzFARklET05FVC5PUkc+tB9KaW0g
R3J1YnMgPDE6MjM0LzFAZmlkb25ldC5vcmc+tBNKaW0gR3J1YnMgPDE6MjM0LzE+
iQCVAgUQKtT1Lm1tOFJzS5pZAQEfUAQAjYXS5sbp/8ewlqx/TAa/S7n9DSgppoBE
Qrqp4uFDInSWvyVz5VsGgbV7tP1Sxntvt9++xwfn2LdSPPDfBLElAiZ+Fd6yRwVd
7wWVbmFml0xFxHwhR6sfovEZ9Mr0RjdeefZhTuN3jWV7EQBHxyFlUQehf7jG104T
n45Sv0x7CIu0FkphbWVzIEMuIEdydWJzIDxXOEdSVD6ZAI0CKtW12AAAAQQArC5O
dv3qYspAvcmybjWopLbXQJ2EINYd3xiTEnKqKkdyytTIDVIFdmd7sbaaAz9fuGZ4
Gg66Fp+Y3PeVYizkiGIMqpxqcXaLbAaO2A+ZCpmYjbB6s9ZzqcjHUsPF1gg7v1Ll
DPDGVA1eNxNqcjpAW1PAfN+mL1UhH8u5b+eWBQEABRG0JVBhdWwgU2NoZW5ja2Ug
PDE6MTM1LzM0MEBmaWRvbmV0Lm9yZz6JAJUCBRAq1k5AbW04UnNLmlkBAS6nA/9B
MkQ9xoehzuOVyvBRqU7dIDiGR2TKp9q+XTe5tflTqfAhGDJeiUrxVt+FsflXJTQg
Hmu6RLXNLyVdZv7N5EyfrQ+SRyxpmPLjsWWCk9CBQ9N0yvGOOgXJHJ/fNDRlW6Ce
67qS0czMyhVe5clvBnGg0dOWddUWOvNYN/u+9G3wxJkAjQIq0f0bAAABBADgjzog
l/b8dE3nct9bIGDrHyLFXMVvcVfK5DUsKvNrah9aGjMF2fPxu5Lujk6btTynY0If
AHuzz/7i7UMfDhLD8YBHBJJNJ28C2TogiIS9jZg+AOWtUvUA+yJ3s1r9CAWgXWFi
hTYWmu6f9FWBq3WnSKYqre6djqPZrd7oItiG4QAFEbQhVG9tIEFsbXkgPHRvbWFA
c2FpbC5sYWJzLnRlay5jb20+mQCNAirQwOsAAAEEAPELC7P7vLHK5hz9urWhk9BJ
+2i9U1Yzzm6MKM/SI+UAVcXsYTP5g9kGJLUpLVq7KxalB1Rqbvg9FjjIaoiQ+ze7
JIPC5X+e0uU43iLMHkgz2mCg56p9hpgkDxwM3R+cHQ1cr2qrSJb8sClbYtknbgec
NM0JMusvUNwtSKqN9fslAAURtExNYXJpYW5uZSBDb3dsZXkgPDE6Mzc3LzNAZmlk
b25ldC5vcmcsIG0ubG92ZUBiaXgsIDcxMzMwLjI3MjFAY29tcHVzZXJ2ZS5jb20+
iQCVAgUQKtEZf21tOFJzS5pZAQHMqAP9EKg/17mW/gi0eWiUT/PpY+R+jBi0VtXA
dq3HZo+VAFEyARt/fqiOuotiC7OFtnsuTPVtarOSxRpz/5bWdIr7AGIdbnwD2dmZ
wvqWDBjvPDzQK1MwPPDpyqRtlEdU9LpwFkn9rVy77KShivrp4xHTVu4RjQUZ8EE5
8ilDyhDolZSJAJUCBRAq0MaYednIlhgdxdUBAaqkA/4gm475FKoXXM9X0/1KH7HR
qAiu+VnrfvljT6GJt8c0BGtVsELLAGODAWCuzmP21IWlRznGvipnFXPoTrfi9bkj
BijCKmdhB/atLi9FB+YO2B3PWtwmUnWbIa7CQO9vxe4t8jYbyDiICAv72dLJXTHg
MxPJAuFIO0ECqScYfb3ol5kAjQIq0LpgAAABBACUmiHr4bN1FBXm/zO/6Yt1bpyZ
rbcxLv/0pFk7/FkaPghdXXyjMZWSnosbw/2dVMMv3R1vJB1mWGl6W+tOkqjeqteO
AE5Cf/iZHTGE4doS0pGdF8wa6e+mPFRZa/lV+3D9Rh0qDqoAlc0FShvd3aGUEI7e
iIB7cGF52ciWGB3F1QAFEbQ9V2VzIENvd2xleSA8MTozNzcvMTQsIDcxNDQxLjMx
NTRAY29tcHVzZXJ2ZS5jb20sIEJpeDp3Y293bGV5PokAlQIFECrQx1HcLUiqjfX7
JQEBEoAD/0YzuJ4LMxKY3CunHyOHmGbAcOEXcG6jqH3GarymZgisy1s1OZB5V5ak
4CzrGCj7Yj8k35KDjp+IcQHDM1JpUDUKB5p1iLblWOWmIa0Zb7SgS4gYDY042knk
leCYpP39mrBC91SSFrGIWjM+wB9J1Izs8N5bWe0EEJonplR701/omQBtAirXWtcA
AAEDALKH2cKuVzOuSo2NTQVwNtiysY+7piD8FZxzjvDGgOYGVJMagPP3ohPmlKVw
mky6ljqtDVaGKDNBmWQlYy4KINpcPI801PtTnqzvLGa3aVs1hMX7mt218hn/G1O2
n+mdCQAFEbQ5RGF2aWQgUG93ZXJzIChkdHApIDxkYXZpZC5wb3dlcnNAZjU0Lm4x
MjUuejEuZmlkb25ldC5vcmc+mQBNAirXO6sAAAECANunzqcH3SLKWFweZ3BAUXO3
OuAISoBxocBtjmgsvndahwdXFGkQzSPgf6uWt3HIksD0a6sKPOrQjUXODZuyxIMA
BRG0OERhdmlkIFRyb3kgUG93ZXJzIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUuejEu
Zmlkb25ldC5vcmc+mQBNAirXWbAAAAECAKOREYOarMoniJ492Q11sfFe5jNAwqb7
p5UyUCPJmcWXZ4mlHIWkmhqOXUM4VArnYKVIrddBDbkaEVBAW2UrY20ABRO0I0No
dWNrIEhheW5lcyA8MTozMDgvNjBARklET05FVC5PUkc+mQCNAirUKygAAAEEALVQ
CansIsa6a+WfQiSOZDko678W7O4A/A7iUmJszodnQD+FVy+L2mcsL9pAjNwhAlHs
Bb35FOVyD9XasQoyVFUZUrF7n6M5RruGGMrs5Pv2m1tVzkeZcSTWyPS7ovLQXRlt
BuS9QbdZu5j8CzMM6g6GvvbqrK01TG5mb1FL1TGDAAURtAtKaW0gQ2FubmVsbJkA
jQIq0KeFAAABBAC72+eRnJzbsIhU9gvXFkTddv48TQY0tQoCo9xa9Y8ocZaaemjQ
4uZqb1Hu0pgcTLdz0fM5FL9ZONnINKLkP+neAHhhY1CVLC/1wi4No4XCUvoW+mrW
d0gO5rZCETi1866/oQNtl5WttsMicmp+955B/y5LL56lj0aWu/QAnbJS3wAFEbRH
UmlkZGxlLCBNaWNoYWVsIEguICA8bWlrZS5yaWRkbGVAaW5ucy5vbWFodWcub3Jn
ICAxOjI4NS8yN0BmaWRvbmV0Lm9yZz6JAJUCBRAq1G3WSrZKvJV4pRcBAQ41BADK
KK/0vQqSZRfNZ48miAHrM7gwMxmLQzncqHC4H0dio3cx5r4frtmILtb75S/RZ5dT
Ghkcyj90F4Zi5S80GvP7LgSOMArzw8WybQWmbWiR55DU6JzSEF8KvX3Re85WCy8m
eV7HxvLJ9aF6vjptfCapqZPHAN2p0AFeIJIRRb0wrZkAjQIqrDZMAAABBADCljOd
puRFotKHCuLtXAtjz8h0+rWr5PTwt0weVwWA3oH93bJXUaZ4yY9a/mjtPBRTvkCx
CPcLQar39Tzz+Yi1+7A9riFZSR9eDD7clbY5vWSm/CTLQlu+NOOQYLRwQvckN1e7
1zVeYzOnRNqHJx+ACP6QRaxiyTyoEwOvWCFMNwAFEbQmSGFsIEZpbm5leSA8NzQw
NzYuMTA0MUBjb21wdXNlcnZlLmNvbT6JAJUCBRAqrjNU4nXeDv9n9wsBAcq1A/97
qFdsvhbonK63dqA2sIDsPRI3MehPk8vT1T6ir35S7NM2Mhn3hVUoAW00gz91/dTd
xevJ8nZfSfVQOkEQhnpRzNXGUbpAidAGGymH6cFDdMYxBh7A63doE+YlpQd7wWb4
vumG7OK0qvoMmc1Ztf/qEazHp99n89q9Ai4FLR6JNpkAPQIq1mizAAABAYDJSSC4
n8a1x/H5CcCW3kh1wGNUPfwMz8mxlctA8f6u9Ba93SoTOl6EhIGsNhM859kABRG0
Fk1hcmMgZGUgR3Jvb3QgKGNhc3VhbCm0I01hcmMgZGUgR3Jvb3QgPG1hcmNAa2c2
a2YuYW1wci5vcmc+mQCNAirWUOIAAAEEAMwYAT+znuzvB5vAdm4jB+EJiKdnoA1E
vxL+Wa4L4W9Q2np1cgblqEvH8uN7nDvy8HX56LMDu6FzlWRHlNqK9z4XgQ7BYKue
vNhcxyHQE5/NxlKtI5oSEg11mLLU5nS0EZ9EUwEhQWMhYI5PitvxTVM9tcKifqW/
BMyG4cAURCo/AAURtCJTdGV2ZSBDbGlmZm9yZCA8MToxMjUvMjA5QGZpZG9uZXQ+
mQBNAirV2r0AAAEB/i78BfdkmEIqKt2EhdlFAJc44rB3ZMzChez5zVcB9jRpUz1o
MY2M2GnucGRUcvMSvZeF/aqCVIHuodDfqyGYYTkABRG0L1NlY3JldF9TcXVpcnJl
bCA8U2VjcmV0X1NxdWlycmVsQFRyZWVob3VzZS5DT00+mQA9AirUzbUAAAEBfjC3
p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xxgMShBCnIZp+xlFiyxQAF
E7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptCZQZXRlciBNIFNoaXBsZXkgPHNo
aXBsZXlAYmVya2VsZXkuZWR1PpkAjQIq0QwSAAABBADUsUTcG5jiohLNic8LAX59
ykQN8vF9CUnB/BQq5au7ShhVYKfAuGztlAkPk0/KdVeXG7Ae+feMpCAHYvZQnn8V
z9I/yHdzQVekNQkOG2JxT3C2pQWes5RiAfUyHcCsXoJapVMVXDwRqb/GGTmCSbjs
Zesexg9tCMydbzScJkT/zwAFEbQpTWFyY29zIFIuIERlbGxhIDxtYXJjb3NAemlw
cHkuc29ub21hLmVkdT6JAFUCBRAq3gxmzT/tLvUlcRcBAV06Af4v/SjkJqxjmSwQ
71TngTsSJEEchXRbGdgHc22eZulnI1BXq2Y+IGpJR1IkQDO9aia17sx/bWi6aY60
lRKe4NzZmQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1i
BQdan0nopm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadI
Dad4g+xIlvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vx
xWtPAAURtDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5k
ZW1vbi5jby51az6ZAE0CKrtlMAAAAQIAwCr9FqO5gRboIusjiAAaXo1gb/erXefm
2czvKvWmzm6ARZgOrxcWCr6oUVd5dFEbIbJPFaz3OJkY/DS+zBmQCQAFE7QqQnJh
ZCBDLiBNY0NhcnR5IDxmNjE3Lm4xMjUuejEuZmlkb25ldC5vcmc+mQCNAiq2rm8A
AAEEAMuZvHCZd4CGhdDcfVfJjx6H/cB5UFJ0FhkzaluDZ37FK7nn9BXhcECVA2o3
TQWPjIh/787s2r3gFSERaI4HlFaXjWvIJ/3BYgkKCxbSmzN9PIrA/QPvNXyv/rE2
XBEFoR9ixWz8W9JEEkkwjSuR3o1/W80iM/sGslOJmEM5slffAAURtCpTaGF3biBL
LiBRdWlubiA8Zjc1NTAubjEwNi56MUBmaWRvbmV0Lm9yZz6JAJUCBRAq0NfZbW04
UnNLmlkBAaxzA/9GvJvWV/Y1URG190TA1epJyUG2RRrtii/bMqgBXKH6kEVhMznJ
0M+/huF4213nctZE08RynCBsgpVxQ+y6oBC/Gxw9Yuci1PAB033+NZAbc7cJaOxg
mZX7PS6o96s1/Rhl2RHlhDscJd9KgX111hLFJBayvOFIfy9Aimt76WFulpkAjQIq
zS3+AAABBACzMsjb4rG9UyVR8oYL7WvZ6Q8BaCSDqSaq7/HK+TqXgjoZE4cYVg/3
WJkmRM8ZbuOwVA49Ssg0Xpj9KINC6dsbMSS5gIhlineM2JR6ioVwICSbsylivDug
Tn2VGxWMAgihqJ2z7Tz3VD6eSgpbkqSwXU9gULJNKJFtbThSc0uaWQAFEbQoQ2hy
aXN0b3BoZXIgQmFrZXIgPDE6Mzc0LzE0QGZpZG9uZXQub3JnPokAlQIFECrQxmzc
LUiqjfX7JQEB/P4D+we6e8+QVJnyYWSWHTKEkUgGZFT9y776QmRmQ3RsnupcY/lh
dl9qwl6IQHdo50CXRghRPukPMz+rU204pKCJLENIWz+cRSHyqdy8nsstOjM4dgoq
WB8h0QchlNavm0LAmKLTCKgJ7WlnGFxHY+ngeqVMbHpbxR/UUAFf3DyYLiTpiQCV
AgUQKtC8BHnZyJYYHcXVAQFqNwP/cktczkLkRwlce+4c7rwvn7nvuuI5gPVlsOdG
LpqtnJ6cEgOPYgzHqW8tQrTecfUTm1TTtVKknwEP5YDxCYDcjlvM31n/S7fr4BeQ
S/uatCxDqho/8kFFbOW4c6fetV3lag0pROxXWlCGYIYJ9dzRViSvvlS4UCHmPbNw
mUdXG1iJAJUCBRAqzWPKGFfk3bG2uCMBASKOA/41iPyVsZbigbE043TQc2O/XTMd
eqyy7P6O7fwE/Q+h5Qthl0pd1SeO3krxqjaXLgjZ07pIsb/+6nhU8UkfCEuFdW9Y
E7ucOIYH2TSnASvv0WA57xbNluPVbui8gBRtrqpoFd9qIynPbhCxuwsqON7tinww
RAygidEyvG4lVVeEq4kAlQIFECrNNyttbThSc0uaWQEB0AAEAIE9A80ah78d5T73
ZmHvHluXjMYBi96N07ix9/wPGa5moEoArV1UL8OZ/OsVXTALH58Pp48m6A96Dz1r
H+uel6Jlu9NyRRNVzw4kXv5dYC8/ou7K7hvgB61ugAxtS7PzzjFrotd9IUDd/bkm
P94lZ0XeFkE3wPlMN1Jlkot5k2X0mQCNAirGZZEAAAEEAL6UcTrYPKFcQjTs1vTb
xGqN1t3WvF2x9N8ZrPfIKwThfPPppUXkCl6Gz0Y/kfu9WbhDoiBnMKIrvXTtsW+h
0f2Lm8Et9RrtMBR9G+CNpIPs+lJNZ9js8rIujX7uanBt/VK/Z0hwdIrzJ8YBEafV
6KJg3lHmfutndxhX5N2xtrgjAAURtDRHSyBQYWNlICBbMTozNzQvMjYgPGdrcGFj
ZUBmMjYubjM3NC56MS5maWRvbmV0Lm9yZz5diQCVAgUQKs3JC21tOFJzS5pZAQHy
JAQAlMgaSBlNourM5deAGSrgqbinr/T/0nNKCfPpZ3SwKe27No+NEbFmHCpPPjrN
SVJoGDN1p8ePSnZdvuqb94cJCGwkdHBWd2c0xAjU4zUY7G+ddogmXfE/7mGdWtXL
7Xtga0vpDZdQ2AubKKCRntaXGNzrqP/5e6csUAhUHd5VLLOZAI0CKrDAUAAAAQQA
tjl87QTiBTb4jkruf5IgK7Ig01Saj/PZQu8ruZTbkJbXqkb9RN7q2bbG8RLYjJxc
EzCR6a9atG7NNteSuQf4/yu52MxmqIF0BikLD3vqtxMSLKYQpGdXjjAS3T4NhBj4
Z7QS3cijYnWpiMmhHb0egsVV1S3hOnIIZitHZ+yaIMEABRG0K0FyamVuIEcuIExl
bnR6IChMRU5UWiBTT0ZUV0FSRS1ERVZFTE9QTUVOVCmZAI0CKm3yLAAAAQQAsYqA
tuURAJ9xkSJD6MEWfDmDQH6jXoYw+yxgEojttaCMZsEOqeRCgwZqA0mlwbm1fZsq
kl16CLTVKnbZA4yllt2u/8pdFYen8mOs0sBken0H6eWixtGs8uEZlkD86DJToPYa
wacwNxNpw8PjfCjWD5FSkO/5SMyv4nXeDv9n9wsABRG0LFBoaWxpcCBSLiBaaW1t
ZXJtYW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+iQCUAgUQKs04AW1tOFJzS5pZ
AQErqQP4zrYEvXhV77y90m2Vew8ZbDD/pxSpVWwgM16uU7CBVlAvMqTs/24qT3qJ
4Pcl2K6P1gCVj0Y+m4PFO07UYEm5UX00BYEZxiFFT4w5CO/4BJfrIu3oIdaadSYx
dBz1uJYZouoE+kEvd35tIppVPXuGLRXdeojXuw/VOGUYgV9aU4kAlQIFECpvUjT0
ygCBjeci2QEBOfsEAL90+6LOAaROuDLyKKvcG8yTSg/HbkRUrpYsX8ya2O9NRvr2
sLx1zehE5/nRUKI1Tk2pzp5J94qaS50mjlW+a7Kf5tMz9JVpDPeU8Y3k7+Pnb+DG
4lhXBkyUvV3AiqK3x89ZW/jRozIHM+JdT7gyUQ3Vtf2P/4zTvlHyocusmGIgmQCN
AipswZkAAAEEAMrcqvIwyKcvxWjFbUIq7/hhzWTrpeThdIxJl7T6P1sX9U6axBhS
a1qE8LxwzTZ7/fhqaUlcZbrho5WODDqge325k7c2DCiIGxG+awndQR7a6X28/U05
aQXQiMnS+IgDOLo6gCtGUFoLDoUob5AuljqHlOrQovmoIPTKAIGN5yLZAAURtCdC
cmFua28gTGFua2VzdGVyICA8bGFua2VzdGVAZndpLnV2YS5ubD6JAJUCBRAqbfKQ
4nXeDv9n9wsBAcIXA/9w7xBNQn8sTkmfBy6S6tFk7GFGHvQA/9eryxHlqjDDhBKQ
eSJJGvPHmNQQ32CnVuv6M54qxT9iusopMv1RFS4ZXTB9u5KV4ajBGvkGfMsHLYgi
AEcdUwndShAm6St/zRoJzQ3ae0mAFk9MYJKYcMuJYL3wCZjrrI5YNrrhSO52w5kA
jQIqezKiAAABBADWbUO71XAVqN9dlef3kGRtlsSA9gnOkoRCzVlo4hFvO792Ie/Y
1p/c5pz2YAyU+9C0beZHVWHwofAdUmdpF3iz2q+4viODLN2UbD2E7hoPjm3HLLjg
iRCKy7lBjtEofLm0TU2mSuAZOR4zKaNcCRcRcSCYtAiJZA/6EarpnZl9RwAFEbQl
UGV0ZXIgR3V0bWFubiA8cGd1dDFAY3MuYXVrdW5pLmFjLm56PokAlQIFECqkeZfi
dd4O/2f3CwEBrsYD/AqgSbc7d3qYO5Gww2MxZX4gA04nzHbyx3XnX6xWUOU6w+Rx
/X/00hP42og+P3Rf+pBg0y4KiIe7hY2TOb6neh3qpcpxkHQKtUkRQd6zYFNRuYoR
NTgeusTiiAv0cL6RYaZFWt44RzbOr3tJZrz3uPHLz2nvDvec4zPHvMoWyeVFmQBN
AiqKPnYAAAECAM4DUPnxdjb43Il+yDkRUO8TgzOW/hjTs1/blllrVe8HDlABqHZM
ib0aNFhKRFYjvsNS3xk34N65vtlI/HoTNvUABRG0IUhhcnJ5IEJ1c2ggPEhhcnJ5
QGNhc3RsZS5yaWdhLmx2PokAlQIFECqmFtb0ygCBjeci2QEBqVwD/A/8vnke2KFN
yFLTOdYhiAZlbpPuo621TIYWVxPJ+D+TVkELdn7HWmDpDGQ8l/7XmuDEBrGjFiQj
1Mv67+rnEqhA4ufKyKS57GuSZ90G99iLLimCiA9ytQyRz8Wi8GUzh2lpv7/478Nv
xEgya3nVM6LwkXodv4OYPVxUnLoSNFGFmQBNAiqc8q0AAAEB/i6Q/XxMaNqWP1tY
4D8vHr5KiwFz1XvE9F5ltPVPeW2I0EORg6u7xSlreXo9OvRd0BbF+UdOAjH7Pwvh
v9xiBCMABRG0IkplYW4tbG91cCBHYWlsbHkgPGpsb3VwQGNob3J1cy5mcj6JAJUC
BRAqp3Bp9MoAgY3nItkBAegyA/sEwCWN7IU1T0NVNkcOcqe+lCn8P42UfX1RUKqC
fErqT51BAPnSIz0naWFQII8ZE41FQQ6iuKnbfKpmIi4VelzcjzsEwdw15cdnyV8O
9FXQ25ysMe1C6LkodMU20XMjH7744n0NG15PWbNcmwNOQ2119tw+u9rRuuC6PFWF
vX0wVZkATQIqxyFfAAABAgDhOocrwWVLJVToItdrune/+sjCF1+GiiEXH1d8Gv8r
B5frpXeGoAtWFvmIpmHgPv21zgcR/2Pykc0/7S71JXEXAAURtDFUb20gSmVubmlu
Z3MgPHRvbWpAZmlkb3N3LmZpZG9uZXQub3JnLCAxOjEyNS8xMTE+iQCVAgUQKtDh
Nm1tOFJzS5pZAQGRrAP+PVrIqMEPeiAmt/K9gjW2xWOVQar5X7v++C/8BqIYj8mm
mGddvQa098te5C1OyunMTK0XtFz7kIvcDJhfKzmp+rdI6TfGURvasmirRFAPxPd9
+lJcIQyInHiRDARFub1xGOQ+Q1ndXsaX1f0O93vz/kjXY0SoC8IURY0OFhPF1paJ
AJUCBRAqy4RiGFfk3bG2uCMBAaH+A/9S3C84z9CK/NLl1Tczz2hxG6R4C41pwPPR
49LX1wNDafec1RyhDUPVP37kc+Rtu6xxZsvsAk19s7KwwYE5Sp+IRsDk8+Qg3545
wfDVUNfV7fShf7ZW3tZY2ybZp3GP3TzH8JFpQjxRy1z1sNyIhZSaNYUb8awDN+uM
mt8zU1SbDw==
=TN0Q
-----END PGP PUBLIC KEY BLOCK-----



--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sun, 25 Oct 92 13:08:18 PPE
To: cypherpunks@toad.com
Subject: re: Re: pgp key distribution
Message-ID: <3270.2AEAFD74@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: shipley@tfs.COM (Peter Shipley)
 U> I maintain two public rings one is a collection I have 
 U> collected via direct contact (friends mostly) the other is 
 U> jyanowitz's list plus random other rings). 

I'm surprised by the number of people who, when they receive a key in
the mail, certify it themselves. I leave mine also uncertified unless
I got it directly. I don't sign nuttin.

--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sun, 25 Oct 92 13:08:19 PPE
To: cypherpunks@toad.com
Subject: re: pgp key distribution
Message-ID: <3271.2AEAFD74@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: pmetzger@shearson.com (Perry E. Metzger)
 U> for the life of me understand why. The only way to know 
 U> for sure that someone's key is theirs is a signature from 
 U> a trusted introducer anyway, so people can just ask each 
 U> other in clear for public keys and it doesn't do a lick of 

I think it is valuable for a number of reasons, none of which are
traditional encryption reasons.

One: Mostly, in my world, I don't need SECURITY, I need PRIVACY. A
paper envelope sealed with water-soluble glue is just fine. It stops
casual snoops, like the lock on your car door does. None of which will
stop a determined thief, but like Eric says, it's economics -- this
level of security is inexpensive as hell.

Two: it gets people introduced to the very basic concept that there
*is* privacy (security) available, and possible. In the FidoNet, and
the BBS world, this is important.

Three: In FidoNet, we've got 16,000 sysops, doubling every 18 months,
worldwide. Traditional key systems are not only wildly impractical,
they're unnecessary for traditional reasons -- who much security to I
need to talk to someone 5,000 miles away I've never met?

Four: If I need *real* security, I will (or better!) obtain keys in
"traditional", secure ways. I can plug these keys into my casual
privacy system, which will hopefully encompass the technological
mechanisms of en/decryption, signing, plaintext handling, and all the
assorted baggage we'll have to drag around anyways.

Five: it will entrench some disasters; bum, or faked keys, humongous
duplicates, inexperienced people forgetting their secret pass phrases
so they can't even issue key-removal certificates (this has happened
already; its a MAJOR pain in the ass), one "person" with a zillion
IDs, inconsistent IDing, etc etc etc etc etc.

Oh well. 

In fact, no system gets implemented right. Period. To pretend it will
is folly. Because of the nature of the beast (patents, feds looking
for backdoors, stupidity, centralist, authoritarian types trying to
exert control, etc, I'm pushing, hard and fast, to get systems set up
LIKE CRAZY of all sorts, with all of them being completely distributed
and decentralized. Sufficiently Paranoid.





--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nathanf@cup.portal.com
Date: Sun, 25 Oct 92 16:21:58 PPE
To: cypherpunks@toad.com
Subject: Removal from list
Message-ID: <9210251610.1.16692@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


Please remove me from the list.
My address is 
        
        nathanf@cup.portal.com

  Thank you.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sun, 25 Oct 92 20:10:41 PPE
To: cypherpunks@toad.com
Subject: Registering Keys with Big Brother
Message-ID: <9210260209.AA18958@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Arise, cypherpunks, evil plans are brewing in the bowels of the Beast!

I just read a summary of influential crypto guru Dorothy Denning's
talk at the recent 15th National Computer Security Conference (held in
Baltimore, don't you know, so con-vee-nient to Fort Meade). See the
recent RISKS articles in comp.risks (esp. 13.86). 

Since RISKS is copyrighted, and we wouldn't to do anything to make the
lawscums unhappy, I'll summarize:

* Denning proposes that anyone using public key encryption over public
networks be required to register their private keys with, for example,
the Justice Department.
* To avoid the risks of someone else getting the key, she suggests the
private keys could be encrypted with the _public key_ of Justice, and
then held by an independent agency. (Ostensibly, the encryption and
registration could be done by the user himself, though some means of
verifying compliance would have to be devised.)
* To make use of the private key (for example, to read e-mail
encrypted with the key), the government would have to get a court
order, present it to the independent agency, take the key back to
Justice, decrypt it with the private key of Justice, and then proceed
with their surveillance and whatnot.

This is ostensibly like the procedure for wiretapping.

However, it would screw up the use of encryption in many ways.
Registering a key would precluded frequent key changes, would probably
cost some fee (on the order of $50, like a driver's license, I'd
guess), and would of course greatly complicate the use of digital
pseudonyms and all the other neat stuff we've talked about (but which
caution tells me not to discuss here on an open and unsecured
list...you can check my .sig to see where I stand, of course).

My hunch is that Denning and the other "quaint" (cf. Sterling's "The
Hacker Crackdown" for a description of how the crypto bigwigs interact
with hackers at CFP and elsewhere) cryptheads have alerted the
government to the _real_ threat of cryto tools. Position papers are
being released as trial balloons, to prepare the way for a "Crypto
Crackdown."

I hope I'm wrong. We need more information. Let's talk to someone who
went to this conference and get the Proceedings as quickly as
possible.

Cryptically Yours,

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Sun, 25 Oct 92 21:29:49 PPE
To: Eric Hughes <hughes@soda.berkeley.edu>
Subject: Re: BBS E-mail policy
In-Reply-To: <9210230601.AA26160@soda.berkeley.edu>
Message-ID: <9210260429.AA29646@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: entropy

I seem to remember that English text is about 1.5 bits per character.  I can
find a reference if you're interested.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Sun, 25 Oct 92 21:41:19 PPE
To: Eric Hughes <hughes@soda.berkeley.edu>
Subject: Re: entropy measures
In-Reply-To: <9210240620.AA08036@soda.berkeley.edu>
Message-ID: <9210260440.AA00199@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>uuencoding will have a slightly lower single-character entropy than
>the ASCII armor PGP uses because just about every line begins with the
>letter 'M'.  This will skew the distribution slightly.  But a better
>way of distinguishing uuencoding and ascii armor is to see that in
>falls in the same entropy class, and then just looking at the
>alphabetic subsets used.

It's not that simple.  The entropy of a byte is the number of bits needed to
represent it.  If what is uuencoded is extremely repetitive, the entropy
will be low, maybe even less than one.  On the other hand, if it were random
data, it would just be slightly lower than ascii armor.  Binaries are
somewhat repetitive, so they have somewhat less entropy than random data.
English has a lot of redundancy, so it has a low entropy.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sun, 25 Oct 92 23:32:00 PPE
To: cypherpunks@toad.com
Subject: Alpha Particles and One Time Pads
Message-ID: <9210260530.AA00679@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Fellow Cypherpunks,

Here's a posting I just sent to sci.crypt, dealing with using alpha
particle sources as noise sources for generating one-time pads.
Ordinarily I wouldn't bother you folks with this, especially since
you're all reading sci.crypt (aren't you? Only the FidoNetters have a
good excuse not to.).

But this thread ties together two aspects of my life, cryptography and
alpha particle errors in chips. 

--Tim

Newsgroups: sci.crypt
Path: netcom.com!tcmay
From: tcmay@netcom.com (Timothy C. May)
Subject: Re: Hardware random number generators compatible with PCs?
Message-ID: <1992Oct26.051612.29869@netcom.com>
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
X-Newsreader: Tin 1.1 PL5
References: <1992Oct25.224554.1853@fasttech.com>
Date: Mon, 26 Oct 1992 05:16:12 GMT

Bohdan Tashchuk (zeke@fasttech.com) wrote:

: The recent post on building a random number generator using a zener diode got
: me to thinking once again about commercial alternatives.
: 
: I haven't seen any commercial alternatives discussed here recently. And since
: the market is so specialized, they may well exist but I'm simply not aware of
: them.
: 
: The ideal product would have the following features:
: 
: 	* cost less than $100
: 	* use a radioactive Alpha ray emitter as the source

It's a small world! In my earlier incarnation as a physicist for
Intel, I discovered the alpha particle "soft error" effect in memory
chips. By 1976 chips, especially dynamic RAMs, were storing less than
half a million electrons as the difference between a "1" and a "0". A
several MeV alpha could generate more than a million electron-hole
pairs, thus flipping some bits.  

(Obviously the effect of alphas on particle detectors was
known, and smoke detectors were in wide use, but nobody prior to 1977
knew that memory bits could be flipped by alphas, coming from uranium
and thorium in the package materials. It's a long story, so I won't
say any more about it here.)

: 	* connect to an IBM PC serial or parallel port
: 	* be "dongle" sized, ie be able to plug directly onto the port, and
: 		not have a cable from an external box to the port
: 	* be powered directly from the port
: 	* generate at least 1000 "highly random" bits per second

This should be feasible by placing a small (sub-microcurie) amount of
Americium-241 on a small DRAM chip that is known to be alpha-sensitive
(and not all of them are, due to processing tricks). Errors would
occur at random intervals, depending on which bits got hit. Getting
1000 errors a second would be tough, though, as such high intensities
would also tend to eventually destroy the chip (through longterm
damage to the silicon, threshold voltage shifts, etc.). If you really
want to pursue this seriously, I can help with the calculations, etc.

: Details:
: 
: Certainly in high volume these things can be made cheaply. Smoke detectors
: often sell for under $10, and have a radioactive source, an IC, a case, etc.

Yes, but smoke detectors use ionization in a chamber (the smoke from a
fire makes ionization easier). That is, no real ICs. But ICs, and even
RAM chips, are cheap, so your $10 figure is almost certainly in the ballpark.

A bigger concern is safety, or the _perceived_ safety. Smoke detectors
have, I understand, moved away from alpha particle-based detectors to
photoelectric detectors (smoke obscures beam of light). Don't
underestimate the public's fear of radioactivity, even at low levels.

: Using a well-designed circuit based on Alpha decay should mean that the
: randomness is pretty darn good.

But not necessarily any better than noise from a Zener. With the
higher bit rate from diode noise, more statistical tricks can be done.
The relatively low bit rate from alpha decay gives less flexibility.
On the other hand, alpha hits are undeniably quite random, with
essentially no way to skew the odds  (unlike with diode noise).

: Everyone these days has either a serial or parallel port available, either
: directly or thru a switch box.
: 
: The tiny "dongle" size is a convenience. If it is small and powered directly
: from the port, there are no cables to get in the way. There is enough power
: available from the signal lines on these ports to power simple devices. E.g.
: most mice don't require an external power supply.
: 
: For most applications 1000 bits per second should be adequate. For example,
: it would be quite adequate for session keys. For generating pseudo
: one-time-pads, an overnight run should generate plenty of values. Continuously
: generating values for a month would produce about 300 MB, which should be
: enough to exchange new CD-ROM key disks once a month.

One time pads are complicated to use. Only very high security
applications that can also afford them use them. For example, some
diplomatic traffic. I can't conceive of a case where 300 MB a month
could be used. 

And _theft_ (or copying) of the CD-ROM one time pads has got to be a
much bigger issue that whether alpha particle noise sources are better
than diode noise sources! By about 10 orders of magnitude I would say.

Black bag jobs on the sites holding the keys will be the likeliest
attack, not trying to analyze how random the noise is (even a fairly
crummy noise source will not yield enough information to a
cryptanalyst trying to break a one-time pad).

Having said all this, I'm glad you gave some thought to alphas. For a
time in the late 1970s this was the chip industry's number one
headache...it was definitely the most exciting time of my life.

--Tim
-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Mon, 26 Oct 92 01:54:38 PPE
To: tcmay@netcom.com
Subject: Re:  Registering Keys with Big Brother
Message-ID: <199210260853.AA20086@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Tim's summary of Denning raises some interesting points, and no doubt this
will end up in the courts in due time.  Some angles of attack which might be
pursued include 2nd amendment (original grounds: protection against tyrrany)
and 1st amendment.  Re the latter, a lawyer I spoke with some years ago,
proposed the idea that freedom of speech in some cases depends on the
ability for the speaker to determine who will and who will not receive what
is said.  

Then of course there is always good oldfashioned civil disobedience.  If
enough people conscientiously violate the regulation, it will become
unenforceable and all the more likely to be overturned.  
-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: efrem@spitha.informix.com (Efrem Lipkin)
Date: Mon, 26 Oct 92 03:52:20 PPE
To: cypherpunks@toad.com
Subject: Re: Registering Keys with Big Brother
Message-ID: <9210261016.AA15135@spitha.informix.com>
MIME-Version: 1.0
Content-Type: text/plain


It seems that registration would defeat the advantage
of a public key system, but it would not prevent private
encrypted messages from being hidden from casual traffic
analysis or even notice by public key wrapping.

This would make registration rather useless against a
conspiracy and thus hard to justify in the face of commercial
and constitutional opposition.

--efrem




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: marc@kg6kf.ampr.org (Marc de Groot - KG6KF)
Date: Mon, 26 Oct 92 03:44:55 PPE
To: cypherpunks@toad.com
Subject: Re: Alpha Particles and One Time Pads
Message-ID: <9210261024.AA11069@kg6kf.ampr.org>
MIME-Version: 1.0
Content-Type: text/plain


Tim May sez:
	Here's a posting I just sent to sci.crypt, dealing with using alpha
	particle sources as noise sources for generating one-time pads.
	
Tim,
Why not use a back-biased germanium diode, or other noisy semiconductor
junction?  Seriously, the NRC has allowed the smoke detector people to
spread those little radioactive chunks of Americium for too long.

John Walker of AutoDesk actually built an IBM-PC card that generated
random numbers from a radioactive source.

All the best,

^M





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 26 Oct 92 08:55:04 PPE
To: cypherpunks@toad.com
Subject: entropy
In-Reply-To: <9210260429.AA29646@soda.berkeley.edu>
Message-ID: <9210261554.AA11701@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Re: entropy

Eric Hollander writes:
>I seem to remember that English text is about 1.5 bits per character.  I can
>find a reference if you're interested.

There are lots of entropies available to measure.  There is "true"
entropy, the lower bound for all other entropy measures.  This is the
compressibility limit.

The entropy I was referring to was simply the single character
entropy.  That is, the probabilities p_i in the entropy expression are
the probabilities that a given single character appear in the text.
This will be higher than the true entropy.  Shannon's estimate for H_1
was 4.03 bits/character.  This assumes a 27 character alphabet.  The
entropy for ASCII-represented English will be higher because of
punctuation and capitals.

The true entropy of English is much lower than this, of course.  But
for an simple measure to automatically distinguish between plaintext
and ciphertext, it should suffice.

Re: uuencoding.  In my analysis before I assume that the uuencoding
would be of random data.  If it is not from random data, then the
entropy will be lower.  Thanks for the clarification.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 26 Oct 92 09:38:01 PPE
To: cypherpunks@toad.com
Subject: Registering Keys with Big Brother
In-Reply-To: <199210260853.AA20086@well.sf.ca.us>
Message-ID: <9210261637.AA12485@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re:  Some angles of attack

George:
>2nd amendment (original grounds: protection against tyrrany)

I've thought for a year or so now that if the State Department was
going to class cryptography as munitions, then they have _de jure_
acknowledged that civilian use of cryptography is protected under the
Second Amendment.  Cryptography is not a weapon and should not be
restricted for public safety reasons.

>1st amendment.  Re the latter, a lawyer I spoke with some years ago,
>proposed the idea that freedom of speech in some cases depends on the
>ability for the speaker to determine who will and who will not
>receive what is said.

This criterion may be valid, but I don't think it's needed.  As I
understand it, the restrictions on speech that do exist restrict 1)
certain contents, not speech as such, and 2) speech which is public,
not private.  Encrypted text, by the fact that it is encrypted, is
intended to be removed from the public domain.  And restricting the
transmission of encrypted text based on some assumed content is prior
restraint.

I'm not sure that any of these arguments really touch a key
registration proposal, unfortunately.  Guns may be sold, but also
registered.  It is not the speech that is restricted, but the privacy
from the Justice Dept. which is restricted.

What I suspect may be more effective is to argue, based on the Tenth
(or Ninth? I get them confused) Amendment, that the Federal Government
has not been granted specific power to require the registration of key
material under any of its other powers.

>Then of course there is always good oldfashioned civil disobedience.

But the percentage of users of cryptography for communications is a
small percentage of the total population as of yet.  

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 26 Oct 92 09:40:33 PPE
To: cypherpunks@toad.com
Subject: Registering Keys with Big Brother
In-Reply-To: <9210261016.AA15135@spitha.informix.com>
Message-ID: <9210261640.AA12615@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>It seems that registration would defeat the advantage
>of a public key system, but it would not prevent private
>encrypted messages from being hidden from casual traffic
>analysis or even notice by public key wrapping.

Sounds like a recipe for selective enforcement, doesn't it?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 26 Oct 92 09:53:38 PPE
To: cypherpunks@toad.com
Subject: entropy
In-Reply-To: <921024155350_74076.1041_DHJ67-1@CompuServe.COM>
Message-ID: <9210261653.AA13072@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Hal:
>Ascii encoding used by PGP reduces this to 6 bits per character
>(e.g. a character set with 64 printable characters) neglecting
>line separators and message beginnings and endings.  So there
>should be a little less than 6 bits per character for encrypted,
>Ascii-encoded messages.

Hal is, of course, right.  I was getting myself confused between
entropy lost in the encoding and the entropy of the encoding.  The
channel uses up two bits of entropy per character in the encoding.
What's left is six bits.

As punishment for getting this so egregiously wrong, I'm going to post
some C code for measuring entropy so that you all can play with it.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Mon, 26 Oct 92 11:22:35 PPE
To: cypherpunks@toad.com
Subject: (fwd) A Trial Balloon to Ban Encryption?
Message-ID: <9210261819.AA07688@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Fellow Cypherpunks,

I have rewritten my posting on Denning's proposal and posted it to
sci.crypt, for wider discussion. I'm surprised the sci.crypt folks had
not already the significance. You might want to consider debating the
issue there, rather than on this list, as your words will then be
heard by more folks and could mobilize an effort against proposal like
this one of Denning's.

Cryptically your,

--Tim

Newsgroups: sci.crypt
Path: netcom.com!tcmay
From: tcmay@netcom.com (Timothy C. May)
Subject: A Trial Balloon to Ban Encryption?
Message-ID: <1992Oct26.180813.7002@netcom.com>
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
X-Newsreader: Tin 1.1 PL5
Date: Mon, 26 Oct 1992 18:08:13 GMT


Is there a trial balloon being floated to effectively ban encryption?

Noted and influential influential crypto advisor Dorothy Denning has
apparently floated the idea of _public key registration_ in a paper or
talk at the 15th Computer Security Conference in Baltimore, held
recently. Discussion of this is in comp.risks ("RISKS"), so far, but
certainly belongs in this group.

I posted a summary of this position to a private mailing list devoted
to crypto issues and got a huge response of concerned folks. I don't
understand why this is not a hot topic on sci.crypt, so I'll post
something right now.

Here's my understanding of her proposal:

* Anyone using public key cryptography would be required to register
the private key with the appropriate authorities, for example, the
Justice Department.

* To head off the obvious concerns about the government routinely
reading e-mail, financial dealings, etc., this registered key would be
stored at an independent agency after first being encrypted with the
_public key_ of Justice. (That is, the independent key storage agency
would have an unusable key, so _they_ couldn't use it themselves.)

* To obtain a usable form of the private key, Justice would have to
get a valid court order, go to the independent storage agency, present
the order, pick up the key, open it with their own _private key_, and
proceed to open mail, read communications, etc.

This is ostensibly the procedure now used for wiretaps.

But the effect on encryption would be chilling:

-would greatly complicate the rapid changing of keys

-would probably be a way to get "unlicensed" crypto programs off the
market (e.g., don't think about using PGP 2.0, as the key registration
authorities would either insist on another algorithm, or would send
the "registration application" to, for example, RSA Data Security for
legal action)

-would undoubtedly require a "fee" (like a driver's license)

-would interfere with the use of digital pseudonyms, anonymous nets (a
la Chaum's "DC Net" proposal, which some of us are exploring now), and
digital money

-would establish the precedent that private communications are not
legal, that copies of all private communications must be placed in
escrow with the government

Registering keys is no different than, for example, requiring a permit
for every public utterance or for registering typewriters, modems,
computers, fax machines, and copiers. Or banning the use of sealed
envelopes for mail. In Phil Zimmerman's great words, it would be like
requiring all mail to be sent on postcards.

My suspicion, which Prof. Denning will presumably comment on if she's
reading this, is that the government folks have come to understand the
profound implications of modern crypto and are looking for approaches
to head off the coming sea changes. Granted, there are serious
national security threats in using modern crypto methods, but there
are in any of the new technologies, such as those listed above.
Besides, does anyone think all keys will be registered? Hiding bits is
a relatively easy thing to do.

This key registration proposal is more odious than the "backdoors in
telecom equipment" proposal discussed here recently.

Can we remain silent as our liberties are taken away?

I think it was John Gilmore who said: "If encryption is outlawed, only
outlaws will have encryption."


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Mon, 26 Oct 92 09:23:21 PPE
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Registering Keys...
Message-ID: <921026155917_74076.1041_DHJ88-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


This proposal to register keys was also mentioned in the July, 1992
Communications of the ACM, in an article by Ron Rivest, one of the
creators of the RSA algorithm.  He was mostly criticizing the proposed
government Digital Signature Standard, stating that he thought that
the NSA was purposely trying to get "weak" cryptography installed as
the standard.  Then he goes on to say,

"Are there technical alternatives that would satisfy all parties?
Perhaps.  It is certainly the case that the formulation of the problem
to be solved has never been made explicit for the cryptographic
community to work on.  I suspect that a solution based on 'escrowed
secret keys' might be workable, wherein each user is legally required
to depost his or her secret key with a trusted third party, such as
the user's bank.  Cryptographic hardware and software would only
operate with public keys that were certified to having their corres-
ponding secret keys appropriately escrowed.  A federal agency could
then obtain the secret key, or its use, with an appropriate warrant.
Once their secret keys were escrowed, multinational corporations could
even operate across borders with a high degree of authentication and
privacy (except perhaps from court-ordered wiretaps).  Cryptographic
hardware and software manufactured in the U.S. would not operate
abroad without public keys suitably certified as having their secret
counterparts escrowed in the U.S.  In an extension of this approach,
users can escrow their secret keys with several trusted third parties
in a 'secret-sharing' manner, so that no single third party can com-
promise the user's key.  While this approach may have its own difficulties,
it does illustrate that weak cryptography is not the only technical
approach available.  There may be much better techniques for achieving
a compromise between a number of conflicting national concerns."

At the time that I read this, I thought it was largely a rhetorical
device, making the point that if the government wants to infringe on
people's privacy, it should come out in the open and do so, rather
than skulking about.  (Like saying, "if the government _really_ wants
to stop sexual immorality it would have to put a TV camera in every
bedroom".) And of course (I thought) this kind of proposal would never
be taken seriously.  I'm shocked that Denning is now advocating it openly.

This proposal makes it illegal for people to communicate so secretly
that the government can't find out what they are saying.  It could
apply to postal mail as well as email - it would be illegal to send
a message via post which the government couldn't interpret.  If this
is really the government's purpose, then it should also require that all
private conversations be recorded, and the resulting tapes be "escrowed"
similarly in case the government needed to find out what was said,
for which it would have to get a court order.

As Tim suggested, this is probably a "trial balloon" being floated to
see what the reaction is.  Let's see that it gets shot down.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Mon, 26 Oct 92 12:13:42 PPE
To: marc@kg6kf.ampr.org (Marc de Groot - KG6KF)
Subject: Re: Alpha Particles and One Time Pads
In-Reply-To: <9210261024.AA11069@kg6kf.ampr.org>
Message-ID: <9210261911.AA12805@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



>Tim May sez:
>	Here's a posting I just sent to sci.crypt, dealing with using alpha
>	particle sources as noise sources for generating one-time pads.
>	
>Tim,
>Why not use a back-biased germanium diode, or other noisy semiconductor
>junction?  Seriously, the NRC has allowed the smoke detector people to
>spread those little radioactive chunks of Americium for too long.
>
>John Walker of AutoDesk actually built an IBM-PC card that generated
>random numbers from a radioactive source.

Q: how hard/cheap will it to build a shielded rs232 plud with a noisy diode
    in it to provide a random number source?


I have written on a possible random number source for Sun SparcStations
(I and II).  I have a program programs the audio chip to take input from
mic port 2 (which is not used in a SparcStation) then I turn up the
gain in the pre-amps and  read the data of the from the DtoA.

I do not know how random it is yet (if anyone wants to run some tests
for me I will be happy to email them the program)


		-Pete




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 27 Oct 92 07:10:21 PPE
To: cypherpunks@toad.com
Subject: re: Re: Registering Keys with Big Brother
Message-ID: <3329.2AECDB78@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: efrem@spitha.informix.com (Efrem Lipkin)
 U> It seems that registration would defeat the advantage
 U> of a public key system, but it would not prevent private
 U> encrypted messages from being hidden from casual traffic
 U> analysis or even notice by public key wrapping.

(Hi Efrem!)

Yes but. The ole "chilling effect". Everyone talks about ENCRYPTION
and SECURITY, what I want is PRIVACY.

You can have privacy today, but if you have to sneak around, if
privacy is not the background assumption, it gravely limits your
ability to live and act freely.

Yes, you will always be able to find co-conspirators, but it would be
a weak version of the world in which we could presume privacy to
begin with.

--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 26 Oct 92 10:08:45 PPE
To: 74076.1041@compuserve.com
Subject: Registering Keys...
In-Reply-To: <921026155917_74076.1041_DHJ88-1@CompuServe.COM>
Message-ID: <9210261643.AA16936@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Hal <74076.1041@compuserve.com>

>This proposal makes it illegal for people to communicate so secretly
>that the government can't find out what they are saying.  It could
>apply to postal mail as well as email - it would be illegal to send
>a message via post which the government couldn't interpret.  If this
>is really the government's purpose, then it should also require that all
>private conversations be recorded, and the resulting tapes be "escrowed"
>similarly in case the government needed to find out what was said,
>for which it would have to get a court order.

>As Tim suggested, this is probably a "trial balloon" being floated to
>see what the reaction is.  Let's see that it gets shot down.

I find it repugnant that we've gone all the way over to the notion
that people must actively cooperate with their own enslavement. We'd
better start getting organized flames against this idea mobilized.
Denning is on the net -- anyone care to start flaming on sci.crypt?
Its likely the place that will get the most response in the general
community.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Mon, 26 Oct 92 12:47:45 PPE
To: shipley%edev0.Tfs.COM@gateway.Tfs.COM
Subject: Re: Alpha Particles and One Time Pads
In-Reply-To: <9210260530.AA00679@netcom2.netcom.com>
Message-ID: <9210261947.AA13100@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



why doesn't someone set up a random number source on a internet host
avalible on a tcp/udp socket? thus if I want some numbers all I have to
do is:

	telnet random_host rand_port > ./random_data_file


the use a pseudo-random generater to select from my random number stream
for a unique random number set.


		-Pete




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 26 Oct 92 12:58:58 PPE
To: cypherpunks@toad.com
Subject: entropy, with code
Message-ID: <9210261958.AA28999@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



The entropy-calculating code is at the end of this message.  I took
the opportunity to calculate some sample entropies:

entropy.c	5.283772	the source code
entropy.asc	6.052222	entropy.c, encrypted and armored 
entropy.as2	6.012493	entropy.asc, with the wrappers removed
entropy.pgp	7.830532	entropy.c, encrypted alone
entropy.obj	6.112890
entropy.exe	6.947111
randseed.bin	4.584963	from pgp, 24 bytes long
pubring.pgp	7.754017	my public key ring

The entropy of the source code is in the high end of the range for
English, which is not surprising given the amount of symbols in
ordinary C code.  The entropy increases with the object and the
executable, each of which has less overt structure to it.

The entropy of the encrypted and ascii armored source code is within
1% of 6 bits, just as predicted.  And with the wrappers removed, it's
even closer!  The binary version of the encrypted message has the
highest entropy of all these tests.

In randseed.bin, the entropy is much less than 8.  But the length of
the file is 24 bytes and log_2 24 = 4.584963, indicating that there
are no duplicate bytes in the file.  Hence the warning:  entropy
calculations with small samples _will_ be misleading.

Note that the entropy subroutine can be used to calculate the
frequencies of any distribution.  This will allow all you code-writing
cypherpunks to measure bit entropies, digram entropies, etc.

Eric

----------------------------------------------------------------

/* entropy.c -- Calculate monogram entropies of standard input.
 */

#include <stdio.h>
#include <math.h>

/* This next define is to counteract the foolish C 7.00 runtime mapping
 * of \x1A to EOF
 */
#define STUPID_NEWLINE_TRANSLATE	1

#ifdef STUPID_NEWLINE_TRANSLATE
#include <io.h>
#include <fcntl.h>
#endif

/*--------------------------------------*/
#define NUMBER_OF_BYTES		256
long byte_freq[ NUMBER_OF_BYTES ] ;

void
main()
{
	int c, verbose = 0 ;
	unsigned int j ;
	double entropy( long *, int ) ;

#if STUPID_NEWLINE_TRANSLATE
	_setmode( _fileno( stdin ), _O_BINARY ) ;
#endif

	for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) {
		byte_freq[ j ] = 0 ;
	}

	while ( EOF != ( c = getchar() ) ) {
		++ byte_freq[ (unsigned int) c ] ;
	}


	if ( verbose ) {
		for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) {
			printf( "%3d=%-3d ", j, byte_freq[ j ] ) ;
			if ( j % 8 == 7 ) printf( "\n" ) ;
		}
	}

	printf( "%lf\n", entropy( byte_freq, NUMBER_OF_BYTES ) ) ;
}

/*--------------------------------------*/
/* Calculates the entropy of the distribution given in list v of n elements.
 * The list v gives counts.  v is summed, and frequencies are assigned 
 * as v[i]/sum(v).
 *
 * Uses the following definitions and identities:
 *   A = \Sum_{i=0}^{n-1} v_i
 *   p_i = v_i / A
 *   H = \Sum_{i} - p_i \log p_i
 *	   = log A - 1/A \Sum_{i} v_i \log v_i
 *   lim_{x \rightarrow 0} x \log x = 0
 */

double
entropy( long *v, int n )
{
	double h ;
	long sum ;
	int j ;

	/* first sum the array
	 */
	sum = 0 ;
	for ( j = 0 ; j < n ; ++j ) {
		sum += v[ j ] ;
	}

	/* next calculate the entropy function
	 */
	h = 0 ;
	for ( j = 0 ; j < n ; ++ j ) {

		/* If the frequency is zero, the entropy contribution is zero
		 */
		if ( v[ j ] == 0 ) continue ;

		h -= v[ j ] * log( v[ j ] ) ;
	}
	h /= sum ;
	h += log( sum ) ;

	/* Now adjust the base of the logarithm to base 2
	 */
	h /= log( 2 ) ;

	return h ;
}





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 26 Oct 92 14:09:43 PPE
To: shipley@tfs.com
Subject: Alpha Particles and One Time Pads
In-Reply-To: <9210261947.AA13100@edev0.TFS>
Message-ID: <9210262036.AA18923@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Peter Shipley <shipley@tfs.com>

>why doesn't someone set up a random number source on a internet host
>avalible on a tcp/udp socket? thus if I want some numbers all I have to
>do is:

>	telnet random_host rand_port > ./random_data_file


>the use a pseudo-random generater to select from my random number stream
>for a unique random number set.

Consider that most people who want to use their random numbers for
cryptographic purposes don't want everyone in the free world able to
read them as they pass through the internet...

In anycase, there is a CALmos device out there that is fairly easy to
use and produces about 20kbits of good random data per second -- not
fast enough for many purposes, but far better than nothing. I suspect
there are other devices on the market, but I haven't researched it
carefully. I can get information on this particular device out to
anyone who is willing to design it into a simple to build RS232
interfaceable box to generate random bits.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Arthur Abraham <a2@well.sf.ca.us>
Date: Mon, 26 Oct 92 22:54:33 PPE
To: hughes@soda.berkeley.edu
Subject: Re:  Registering Keys with Big Brother
Message-ID: <199210270553.AA26809@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Seems to me that there would be a certain amount of trouble with people
registering one private key but communicating with another they had 
forgotten to register.  Bad situation for my large sibling 'cause he 
wouldn't realize this until after the court order etc.  A good solution
would be BIG fines for mis-encryption and sampling of messages to make sure
they were properly formed -- for our own protection, of course.  And if
they happened to radomly sample something they didn't like... for instance 
finding my obviously excessive paranoia....

-a2.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Tue, 27 Oct 92 00:24:43 PPE
To: Arthur Abraham <a2@well.sf.ca.us>
Subject: Re: Registering Keys with Big Brother
In-Reply-To: <199210270553.AA26809@well.sf.ca.us>
Message-ID: <9210270724.AA29964@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


Arthur Abrahams incisively notes:
> Seems to me that there would be a certain amount of trouble with people
> registering one private key but communicating with another they had 
> forgotten to register.  Bad situation for my large sibling 'cause he 
> wouldn't realize this until after the court order etc.  A good solution
> would be BIG fines for mis-encryption and sampling of messages...

There is no need for sampling of messages.  You don't understand the
theory of power.  Simply make the penalty for encryption without registry,
larger than the penalty for any other crime.  Then no crime can be hidden
behind it.  It's like getting Al Capone for income tax evasion; if you
investigate someone and they are enforcing privacy on their communications,
you can put them in jail for life for that, and can stop worrying about the
original suspected offense.

	John





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 27 Oct 92 06:25:26 PPE
To: cypherpunks@toad.com
Subject: re: Registering Keys...
Message-ID: <3336.2AED0EE9@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: 74076.1041@CompuServe.COM (Hal)

 U> This proposal to register keys was also mentioned in the 
 U> July, 1992 Communications of the ACM, in an article by Ron 
 U> Rivest, one of the creators of the RSA algorithm.  He was 

 U> solution based on 'escrowed secret keys' might be 
 U> workable, wherein each user is legally required to depost 
 U> his or her secret key with a trusted third party, such as 
 U> the user's bank.


Actually this sounds signifigantly different from what Denning is
allegedly proposing.

This method is analogous to the way FFL (Federal Firearm License)
holders record transactions of gun sales (I have an FFL). FFL holders
are required to record, in detail, each transaction based upon gun
serial number/description, and to/from addresses (buy/sell). The FFL
holder maintains the records; the feds dont' get a copy.

If a gun is used in a crime, the feds go to the manufacturer, and
follow the audit trail of FFL records to follow that guns travels.

This is *completely* different than a centralized gun database, where
a hypothetical they can compile cross indices based upon oh say name
or address or whatever. 

The third party escrow method puts the same sort of restraint upon
searches. I'm not saying I particulary like the method, it's just that
it's qualitatively different. The BATF cannot rummage through the
audit trail of FFL records, they can only follow the forward/backward
pointers per gun. Rivest seems to imply there could be many,
independent key-escrow locations. A hypothetical we could form our own
key escrow, and while we'd be subject to whatever the hypothetical
they would require for access, we could probably do things ilke inform
members of all key accesses/inquiries, etc.

In short, it bothers me a lot less than Dennings.

--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Tue, 27 Oct 92 01:31:25 PPE
To: pmetzger@shearson.com
Subject: Re: D-H telnet protocol  *  Cheap secure phones
In-Reply-To: <9210221929.AA16268@newsu.shearson.com>
Message-ID: <9210270831.AA29372@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> >					(It doesn't protect against
> >active re-routing of the call, e.g. by substituting another machine
> >for the BBS, but we could work on that as Phase II.)
> I would suggest that it be done during phase one. Spoofing attacks are
> very important things to guard against, ...

Fine, Perry.  You do it.  I want to get some "easy" protection out
there now.  Easy often turns out to be six months of work all by itself.

> suggest that the protocol be designed so that it does not reveal the
> entities forming the link to outsiders (unless one end should
> intentionally advertise who it is...

This is the intent.  The D-H protocol will not reveal any identifying
information, and the rest of what is transacted will be protected under
the secret key produced by the D-H protocol.

> I am very interested in seeing such a protocol standardized because I
> have another use for it -- secure telephones. Given modern DSPs to do
> and cheap V.32bis modems, excellent secure voice communications are
> feasable.

There's a "CELP" standard for voice encoding which you can get from
the Feds.  They used it as an upgrade in STU-III secure phones.  It's
Federal Standard 1016.  It encodes voice at 4800 bits per second with
better quality than any known algorithm under 16,000 bits per second
(so says the paper on it).  If you give it 16 kbits/sec, it is "toll
quality".

You can get a free copy of the standard, a "technical information
bulletin 92-1" entitled "Details to Assist in Implementation of Fed
Standard 1016 CELP", and four floppies full of C and Fortran software
that implements it, plus test cases, by requesting it from:

	Office of the Manager
	National Communications System
	Attn: NT
	701 S. Court House Road
	Arlington, VA  22204
	+1 703 692 2124

Note that this C and Fortran code doesn't run in realtime on workstations;
it requires a DSP.  But as the "Implementation Details" paper says:

	"A high-quality, low power, small-sized voice processor can be
	constructed for under $200 parts cost in small quantities by
	adding to one of these [TMS320C31, DSP56001] DSP chips: ROM,
	16k words of SRAM, and a Texas Instruments TLC32044 A/D and
	D/A with filters chip."






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Tue, 27 Oct 92 02:39:00 PPE
To: shipley@tfs.COM
Subject: Re: Alpha Particles and One Time Pads
Message-ID: <199210270938.AA27715@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Re Pete's proposal for an on-net random source which could be accessible to
users who would then use a psuedo-random process to select which bits to use
in compiling cypher keys:

What you'll get will be superencipherment, which is no more secure than the
links in the chain.  The random stream would be non-secure; and so we're
left with the security of the psuedo-random selection process.  

To analogise somewhat, white noise put through a filter has the
characteristics of the filter.  Try it with FM static and a graphic
equaliser.  

Now to play devil's advocate here, I wonder if a less-than-perfect physical
random source would be acceptable, since the potential domain of decryptions
would be large enough that unicity in cryptanalysis would in practice be
unattainable.  What do you think...?




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Tue, 27 Oct 92 02:08:56 PPE
To: tcmay@netcom.com (Timothy C. May), cypherpunks
Subject: Re: A Trial Balloon to Ban Encryption?
In-Reply-To: <9210261819.AA07688@netcom2.netcom.com>
Message-ID: <9210270908.AA00325@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> I think it was John Gilmore who said: "If encryption is outlawed, only
> outlaws will have encryption."

Maybe.  But I like John Perry Barlow's formulation better:

"You can have my encryption algorithm when you pry my cold dead fingers
from its private key."

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hkhenson@cup.portal.com
Date: Tue, 27 Oct 92 09:21:45 PPE
To: cypherpunks@toad.com
Subject: Re: Registering Keys with Big Brother
Message-ID: <9210270726.1.5339@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


One consequence of this proposal would be the capturing of *all* email
traffic for (possible) subsequent decryption under a court order.  After
all, how could you complain?  They couldn't read your messages of the
last ten years unless they happened to get a court order.  Knowing how
easy it is to get a pliant judge to issue an order, this would be 
really chilling.  Keith Henson

(on the other hand, the media makers would love it.)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hkhenson@cup.portal.com
Date: Tue, 27 Oct 92 09:22:00 PPE
To: cypherpunks@toad.com
Subject: Re: Registering Keys with Big Brother
Message-ID: <9210270747.1.5339@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


Eric mentioned that this topic sounds like a recipe for selective
enforcement.  If all traffic were captured for possible subsequent
analysis, they could get you for a noise burst on a communication
line.  Couldn't decrypt that even with your key.  Keith




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Tue, 27 Oct 92 09:08:54 PPE
To: gnu@toad.com
Subject: D-H telnet protocol  *  Cheap secure phones
In-Reply-To: <9210270831.AA29372@toad.com>
Message-ID: <9210271539.AA05477@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: gnu@toad.com

>> >					(It doesn't protect against
>> >active re-routing of the call, e.g. by substituting another machine
>> >for the BBS, but we could work on that as Phase II.)
>> I would suggest that it be done during phase one. Spoofing attacks are
>> very important things to guard against, ...

>Fine, Perry.  You do it.  I want to get some "easy" protection out
>there now.  Easy often turns out to be six months of work all by itself.

Why should "hard" be that much more difficult? Looks like an extra few
days worth of work if you pull all the public key code from PGP.
Admittedly, this would be a big project if one couldn't steal existinc
dode, but remember, PGP is copyleft. This whole project is a humungous
patent violation anyway, so there is no good reason for not stealing
code from PGP. Phil's code is bloody good.

Anyway, the "easy" protection is probably the "hardest" part. Getting
the encrypted link and drivers running properly is the big deal --
thats the code that will take all the time. Its likely marginal cost
to design the protocol "right" from the beginning to make it easy to
plug in verification later, and being able to use existing public key
code to implement it likely removes most of the sting.

All you have to do in order to "fix" things is have both sides public
key encrypt their D-H exchanges, and suddenly, you have verification
of identity.

>> suggest that the protocol be designed so that it does not reveal the
>> entities forming the link to outsiders (unless one end should
>> intentionally advertise who it is...

>This is the intent.  The D-H protocol will not reveal any identifying
>information, and the rest of what is transacted will be protected under
>the secret key produced by the D-H protocol.

Ah, but if you want to add in a verification layer, you have to be
careful to make sure that you don't reveal too much information in
doing the verification.

>> I am very interested in seeing such a protocol standardized because I
>> have another use for it -- secure telephones. Given modern DSPs to do
>> and cheap V.32bis modems, excellent secure voice communications are
>> feasable.

>There's a "CELP" standard for voice encoding which you can get from
>the Feds.

Well aware of it; I've got sample source code for CELP and all the
rest.  However, having a standardized bunch of software for encrypting
the link will mean that I have that much less to worry about.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 27 Oct 92 11:57:12 PPE
To: cypherpunks@toad.com
Subject: list status
Message-ID: <9210271856.AA03357@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



As of today, the list stands at 121 members, at least one of which is
a mail gateway.

Breakdown of the list by top-level domain:

U.S. domains:
  42 com
  42 edu
   1 gov
   1 mil
  10 org
   6 us

All other domains:
   1 at
   3 au
   1 ca
   1 de
   2 il
   1 nl
   2 no
   1 nz
   1 pt
   1 se
   4 uk
   1 za


Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: clarka@netcom.com (Andrew Clark)
Date: Tue, 27 Oct 92 12:37:03 PPE
To: cypherpunks@toad.com
Subject: Please remove me from the mailing list / thanks
Message-ID: <9210271930.AA19861@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



clarka@netcom.com     Andrew Clark     My ignorance is my own fault.
"We have virtual reality today: George Bush lives in it." | Bad cop! 
"Macs are to computing what television is to journalism." | No donut! 
Secondary account at aclark@UCSD.EDU -- prefer mail at netcom site.   




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 27 Oct 92 13:26:24 PPE
To: tenney@netcom.com
Subject: Hackers Conference--Crypto Session
Message-ID: <9210272023.AA26749@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain




Glenn Tenney, chairman of the Hackers Conference, has asked me to help
put together the crypto session at the Conference next week (6-8
November, Lake Tahoe). I of course agreed....our correspondence is
attached below. Sorry if I left off your name in my comments to Glenn
...it seems sometimes that nearly everyone I know has some interest in
crypology, privacy, cyberspace, AND is going to Hackers! For those not
going to Hackers this year, I'd still like your inputs, and I'll write
up some kind of update after it's over, so you'll get some feedback on
your ideas.

This growing interest in cryptology and the protection of
privacy--fanned by the availability of PGP 2.0, the books and articles
on hackers and crackdowns by the Feds, the activities of the EFF and
CPSR, and by our very own "Cypherpunks" crypto group--should make for
an extremely interesting time at Hackers this year.

Just about every year at Hackers there's a de facto theme. One year it
was hypertext (and Xanadu got started when John Walker of Autodesk met
Ted Nelson, Mark Miller, Roger Gregory, and others at Hackers in
1987), another year it was multimedia. Last year it was effectively
the EFF, and so on. My hunch is that this year the de facto theme
_could_ turn out to be crypto tools and digital protection of privacy.

In addition to our session, there will be discussions of wireless
communication, the work of the EFF, and a Sunday discussion of these
critical issues. These will all fit nicely with our own session.

Our session is in "prime time," mid-Saturday afternoon, tentatively
(you all know how schedules change!), and is one of the "no
competitors" tracks, so attendance should be very high. Accordingly,
some premium should be placed on organization, to maximize the
information flow. Too many people for the "circle discussion" that
worked so well at last year's nanotechnology session (run by Ted
Kaehler), so we need to figure out a good format.

So give me your inputs! (Also, I think we should get togther
informally Friday to bounce ideas around, the better to make the
session on Saturday richer and more exciting. I'll let you know in the
next several days what we decide, and where we'll meet.)


* What topics need to be discussed the most? 

* What format? Panel discussion? A series of mini-lectures on the
various topics? Free-for-all discussion? (Remember that we'll probably
be in a big room, with perhaps as many as 100-150 attendees.)

* Some ideas for topics (which I'll add to as people make
suggestions):

- A very brief review of modern cryptology (very brief because we need
to move on quickly to the juicy stuff), including snapshot summaries
of encryption, RSA (but no number theory!), anonymous mail, digital
cash, etc. (Too many crypto panels spend the entire time bringing
people up to speed on what prime numbers are, on how one-time pads are
used, and so on. I favor giving people a good glimpse of the
"exciting" stuff--anonymous mail, digital pseudonyms, information
markets, dining cryptographers protocols, etc.--and then letting them
go back and fill in the background. Give 'em a glimpse of the Promised
Land.) 

- The uses of digital remailers to protect privacy, and progress on
building them (a brief summary)

- Possible summary of the "Crypto Anarchy Game" we've been
experimenting with here in our Cypherpunks group (Note: we could
describe it briefly and then invite folks to play it later that
evening, perhaps around midnight)

- PGP 2.0...what it is, how to get it, and how to use it

- Proposed legislation for trapdoors in telephone equipment, and the
possibility that crypto keys may be placed under strict controls (a la
my recent post on Dorothy Denning's latest trial balloon)

- What we can do about these trends, what we as hackers can do to
protect our privacy. Things like: deploying encrypted e-mail as
quickly as possible, using digital pseuodonyms, deploying "mixes,"
arguing for basic constitutional protections, etc.


Ideally, people will get so worked up and excited that the rest of the
Conference will be buzzing about these issues!


Here's Glenn's message to me and my acceptance:

> > Considering your keen interest in cryptography, I was
> > wondering if you could have your arm twisted to help
> > pull together the crypto session for the conference?
> > 
> > It should be fairly easy...  Let's see, Eric Hughes will
> > be there, as will a couple of guys from BellCore (Sternetta
> > and ... ??? ). 
> > 
> > If so, plesae let me know and I'll pass on some more names.
> > 
> > Thanks much.
> > Glenn Tenney
> 

> Of course I'll help. Anything needed, including what you suggest.
> 
> I'm in regular contact with Eric Hughes, John Gilmore, Fen LaBalme,
> Hugh Daniel, Keith Henson, and others. I also know Stu Haber, from
> Bellcore...if he could speak briefly about digital timestamping of
> documents (and Internet mail applicaitions) that would be timely.
> 
> So I'll so whatever I can.
> 
> BTW, I'll forward my latest posting from sci.crypt about proposals to
> require all crypto keys to be registered with the government! That,
> alone, is worth of a "hacker politics" discussion at Hackers.
> 
> --Tim (408-688-5409)


..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Tue, 27 Oct 92 13:24:00 PPE
To: hughes@soda.berkeley.edu
Subject: list status
In-Reply-To: <9210271856.AA03357@soda.berkeley.edu>
Message-ID: <9210271954.AA07709@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Eric Hughes <hughes@soda.berkeley.edu>
>Breakdown of the list by top-level domain:

>U.S. domains:
>  42 com
>  42 edu
>   1 gov
>   1 mil
>  10 org
>   6 us

Hmm... Wonder who Mr. .gov and Mr. .mil are...

(1/2 :-)

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Tue, 27 Oct 92 19:17:46 PPE
To: cypherpunks@toad.com
Subject: Re: D-H telnet protocol
In-Reply-To: <9210271539.AA05477@newsu.shearson.com>
Message-ID: <9210280200.AA24003@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


> Why should "hard" be that much more difficult? Looks like an extra few
> days worth of work if you pull all the public key code from PGP.

The project as I plan it, would require no administration on the part
of users.  Install and forget.  If you add authentication, then
end-users have keys to deal with, on an ongoing basis.

As I said before, you're free to take what I come up with and add
authentication.  But stop berating me in public for doing something
to further the use of cryptography.

> 				This whole project is a humungous
> patent violation anyway, so there is no good reason for not stealing
> code from PGP.

You have made two bad assumptions here.  I do not intend to violate
any patents, nor do I intend to steal code from PGP.  I'll be glad to
talk in private about what is happening, but it is not ready for
public discussion yet.

> All you have to do in order to "fix" things is have both sides public
> key encrypt their D-H exchanges, and suddenly, you have verification
> of identity.

This is not true.  I have a preprint of a paper by Whit Diffie that
explains how to weave D-H and RSA together so that you can't accept
the authentication but be spoofed on the key exchange, or vice verse.
It starts with a simple protocol as described above.  Known attacks
are explained and the protocol is modified to deal with them.  The
result is now in use in commercial products (secure phones).  It's not
as simple as it looks.

	John Gilmore





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Tue, 27 Oct 92 19:18:01 PPE
To: cypherpunks@toad.com
Subject: One-time pads and DC Nets
Message-ID: <9210280211.AA19676@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Regarding the previous discussion about one-time pads, there is
another use for disks full of random numbers.  They can be used to
implement Chaum's DC-nets.  For the degenerate case of just two people
communicating, the DC-net is similar to using a one-time pad.
However, what you are hiding is not _what_ you are sending, but _who_
is sending it.

DC-nets ("DC" stands for "Dining Cryptographers", the example Chaum
used to introduce the idea) are designed to hide message sources among
some group of people.  The people have to be fairly well connected,
with near-real-time communications capability.  It won't really work
for people exchanging email.

For the simple two-person case, suppose as in the case of the one-time
pad that each person has an identical CD-ROM filled with random bits.
What they do is, at some predetermined rate, each person just
transmits the bits off his pad.  Both people are sending the same
bits.

When one wants to send a message, he starts toggling certain of his
bits.  To send a "1" he sends the opposite of the next bit from the
one-time pad; to send a zero he sends the correct version of the next
bit from the one-time pad.

Assuming they don't start transmitting at the same time, what an
outside observer will see is that, where before they were both
producing exactly the same bits, now they are producing a certain
number of opposite bits.  Interpreting each opposite bit as a 1, and
each case of same bits as a 0, produces a recognizable message.

But, the outside observer can't tell which person is sending that
message.  All he sees is two totally random streams of bits, which
disagree at certain spots.  Without access to the one-time pads, there
is no way for him to tell who is sending.  (Of course, the two people
involved know who is sending, since one of them is and one of them
isn't.)

Generalizing to larger numbers of people, you need to have a separate
one-time pad shared with each other person in the group.  In other
words, for a group of N people there has to be a total of N(N-1)/2
one-time pads; each person has N-1 of them.  That is, for each pair of
people in the group, there is a unique and secret one-time pad which
they share.  (This is for maximal security - you can get by with fewer
pads if you trust each other some.)

Now, they all send all the time.  What they send is the "XOR" of the
next bits of all their N-1 one-time pads.  It turns out that if you
then "XOR" everybody's output bits, you'll get nothing but zeros as a
result.  When someone wants to send, he sends the opposite of what he
normally would for a "1", and he sends just what he normally would for
a "0".  Collisions can be handled like ethernet - back off and
retransmit.  (Chaum had another way involving reserving future blocks
of transmit time.)

With N people sharing N-1 one-time pads per person, nobody can tell
who is transmitting.  All anyone knows is whether he himself is
transmitting or not; all an outside observer knows is that someone in
the group is transmitting.

DC-Nets eat up one-time pads even worse than using them for message
secrecy does.  But, with CD's, you can put a lot of data on a pad.
And the system is fairly robust against pads being stolen.  If one
person's one-time pads are all secretly copied by a spy, then he can
tell if that person is sending.  But he learns absolutely nothing
about which other people are sending.

I wonder if it would be possible to experiment with a DC-Net system in
the Internet environment.  I recently acquired an account on a system
with Internet connectivity (I know because I can telnet and ftp from
it).  I've done considerable programming with Unix socket
communication in systems connected by ethernet, and I think the
Internet provides a very similar programming interface.  It shouldn't
be that hard to create a very simple "chat" program in which message
sources are strictly anonymous (assuming the existance of the required
one-time pad random-number files - for testing, they could be created
by random number generators at each end, started with identical seeds).
I'll try some experiments along these lines over the next few days.

Hal
74076.1041@compuserve.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Tue, 27 Oct 92 17:23:08 PPE
To: cypherpunks@toad.com
Subject: Threat to our privacy
Message-ID: <9210272346.AA11735@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


For Cypherpunks: A copy of mail I just sent to...
       libernet@dartmouth.edu, extropians@gnu.ai.mit.edu,
       prz@sage.cgd.ucar.edu, mike@eff.org, mkapor@eff.org


[This is being sent out to a wide audiance. If you receive this, its
because 

My friends, its rare of me to try to encourage panic. Occassionally,
however, by panicing early we can avert a disaster later on.

Risks, an internet mailing list, reported about a week ago on a
proposal by Dr. Dorothy Denning, one of the most prominent people in
the field of cryptography, that copies of all private encryption keys
associated with public key cryptographic systems be held, effectively
by the government, to permit them to read people's encrypted messages
to each other. Naturally, such invasions of privacy will only be
permitted "when a warrant is produced". It has been suggested that
this idea might be taken up by several government agencies for
"review".

Many have noted that the dawning of cheap and effective cryptographic
systems could spell the end of the ability of governments to invade
people's privacy. Unfortunately, it appears that the government and
its cronies have also realized this, and intend to take preemptive
action. Our notion of civil rights has decayed so far that it is now
considered a citizen's duty to not merely be quiet while he is
enslaved but to actively cooperate with his own enslavement. Not
merely must we put up with the indignity of the government being
granted the right to read our papers and communications to each other,
not merely has the FBI attempted to get legislation passed to make
phone companies give them easier access to tap phone lines under color
of "maintaining the current capability in the presense of new
technology", but now it is suggested that we ordinary citizens must
personally cooperate to make it easier for them to read our
communications. We will be branded criminals if we fail to cooperate,
presuming that ideas like this are enacted.

It is crucial that the fiends proposing this be convinced that
resistance will be too high to implement their plan. It is crucial
that before they can even propose legislation that the threat here be
brought to the attention of the news media. If the currently proposed
FBI legislation were passed, a dictatorial government would have all
the tools it would need to tap all the phones in the country -- the
only thing restraining that behavior would be a system of warrants
that could disappear with a mere change in attitude. If Denning's more
serious and sinister idea were proposed for future enactment as
legislation (this has not yet been proposed), it would become
impossible for individuals to take any action to protect their own
communications privacy from a dictatorial regime, even ignoring the
question of abuses that could occur right now. I'm convinced that the
only thing that prevented the FBI bill from passing this year was the
fact that media attention was brought to bear. Its important that this
new proposal be exposed to similar sunshine. Far be it for me to
suggest restraint of free speech, but I would like to see people
think of making such suggestions as having the social acceptability of
calling a black person "nigger".

Here, for reference, is a copy of an article Dr. Denning just posted
to sci.crypt on usenet.

I encourage people, rather than discussing this matter on libernet or
extropians, to discuss this on sci.crypt where the topic is just
breaking.

Perry Metzger

----------------------------------------------------------------------

Article 6275 of sci.crypt:
Path: shearson.com!uunet!uunet!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!darwin.sura.net!guvax.acc.georgetown.edu!denning
From: denning@guvax.acc.georgetown.edu
Newsgroups: sci.crypt
Subject: Re: A Trial Balloon on Registered Keys
Message-ID: <1992Oct27.143737.1574@guvax.acc.georgetown.edu>
Date: 27 Oct 92 14:37:37 -0500
Distribution: world
Organization: Georgetown University
Lines: 94

The posting about the proposal I made at the NCSC for key registration
is essentially correct.  Let me add to it the following:

1.  The government is not taking any action to curb crypto and is 
unlikely to take any such action in the near future.  No proposal has
been made and no government agency that I am aware of has plans to
make such a proposal. The closest we've had to a proposal was a "Sense
of Congress" resolution in Senate Bill 266 over a year ago.  This 
would not have mandated anything, but said it was the sense of 
Congress that service providers should provide accesss to the 
plaintext of encrypted communications under a court order.  It got a lot of 
opposition and was withdrawn.  Thus, don't panic folks -- this was just me
making a suggestion.  I didn't realize I had that much clout to cause
such a stir and call to arms!  I expect that the next step will be government 
sponsored discussions about crypto policy, probably sponsored by NIST,
at the recommendation of the Computer System Security Advisory Board
headed by Willis Ware.  That will provide a forum to work through these 
issues.  

2.  The reason I made the proposal is because I am concerned that we
may be facing a major crisis in law enforcement.  I expect many of
you will say "that's wonderful" but I don't see it that way.  
Electronic surveillance has been an essential tool in preventing 
serious crimes such as terrorist attacks and destabilizing organized crime.
The economic benefits alone are estimated to be in the billions.  This
issue is not about snooping on innocent citizens but about doing what
we can do prevent major crimes that could seriously disrupt other
liberties.  The problem is likely to get even worse if criminals know
they use the telecommunications systems without any chance of getting
caught.

3.  My proposal was to register your private key with a trustee, 
different from the government.  The key would be encrypted under some
other public key so the trustee couldn't decrypt it.  I have suggested
it be the key of the DOJ, but it could be another independent trustee.
I believe this would provide acceptably good protection since someone
would need to get a court order and then the cooperation of 3 agencies
to get at your communications: the telecommunications provider (to get
the bit stream), the first trustee (to get the encrypted key), and
the second to decrypt it.  Experience with the telecom providers has
been that they are very fussy about court orders -- you have to get
the semicolons right!

You can get even more security by using Silvio Micali's "fair 
public-key cryptosystem" approach.  Called "fair" because it is 
designed to strike a balance between the needs of the Government and
those of the citizens.  With his approach, you would break your key
up into 5 parts and give it to different trustees.  All 5 parts
are needed to reassemble it, but it is possible to veryify the parts
individually and as a whole without putting them together -- 
ingenious!  He presented this at CRYPTO '92. 

4.  Someone suggested that law enforcement routinely taps without
court order.  This is an ungrounded claim for which I have never
seen any evidence.  Regardless, their ability to do this is 
disappearing with the new digital based technologies.  They need the
help of the service providers, who in turn ask for court orders.
Court orders are not all that easy to get as law enforcers have to
document why other approaches have failed etc.

5.  Many people have noted that you could not enforce key 
registration.  They may be right, but I am not throwing in the towel
yet.  Let's take phones, which is what law enforcers are most 
interested in.  Products are emerging that you can attach to your
phone and that will do DES encryption.  Criminals and everyone
else are most likely to use commercial products -- easiest to
get and cheapest.  The products could be designed so key registration
would essentially be part of the sales process.

There can be social benefit to government regulation even when 
regulation is not 100% successful.  None of our laws prevent the
acts they outlaw.  But this does not mean we should get rid of
all laws.  

6.  Some people have said we should not give up our privacy to the
government.  But the constitution does not give us absolute privacy.
We are protected from unreasonable searches and seizures, but not
reasonable ones in response to "probable cause" of crime.  In all
areas of our lives, the government can invade our privacy if they
have good reason to believe we are engaged in major criminal activity.
They can break into our homes, our safes, and so on.  Do we really
want a society where electronic communications cannot ever be broken
when there is good reason to believe some major threat against society
is being planned?  

Thank you for your comments and for encouraging those on the other
news groups to move over to sci.crypt.  I'll try to keep up with
this newsgroup and respond to other comments if appropriate, but
I honestly can't track them all.

Dorothy Denning
denning@cs.georgetown.edu (posting from guvax)




----------------------------------------------------------------------




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 27 Oct 92 20:06:05 PPE
To: cypherpunks@toad.com
Subject: Messages in the Least Significant Bits
Message-ID: <9210280303.AA21744@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks,

Here's a message I just posted to another mailing list. It has rather
strict policies against cross-posting, so I've edited out the headers
and the initial chunk of text I quoted. That should make me kosher.

(This topic also came up in some e-mail with George Gleason.)

Forwarded message:



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Anonymous
Date: Tue Sep 07 12:36:54 1999
Subject: No Subject
Message-ID: <d41d8cd98f00b204e9800998ecf8427e@NO-ID-FOUND.mhonarc.org>
MIME-Version: 1.0
Content-Type: text/plain


xxxx is exactly right on this. Several years ago I posted to sci.crypt
my "novel" idea for packing bits into the essentially inaudible "least
significant bits" (LSBs) of digital recordings, such as DATs and CDs.
Ditto for the LSBs in an 8-bit image or 24-bit color image. I've since
seen this idea reinvented _several_ times on sci.crypt and
elsewhere...and I'm willing to bet I wasn't the first, either (so I
don't claim any credit).

A 2-hour DAT contains about 10 Gbits (2 hours x 3600 sec/hr x 2
channels x 16 bits/sample x 44K samples/sec), or about 1.2 Gbytes. A CD
contains about half this, i.e., about 700 Mbytes. The LSB of a DAT is
1/16th of the 1.2 Gbytes, or 80 Mbytes. This is a _lot_ of storage!

A home-recorded DAT--and I use a Sony D-3 DAT Walkman to make
tapes--has so much noise down at the LSB level--noise from the A/D and
D/A converters, noise from the microphones (if any), etc.--that the
bits are essentially random at this level. (This is a subtle, but
important, point: a factory recorded DAT or CD will have predetermined
bits at all levels, i.e., the authorities could in principle spot any
modifications. But home-recorded, or dubbed, DATs will of course not
be subject to this kind of analysis.) Some care might be taken to
ensure that the statistical properties of the signal bits resemble
what would be expected with "noise" bits, but this will be a minor
hurdle.

Adobe Photoshop can be used to easily place message bits in the
"noise" that dominates things down at the LSB level. The resulting GIF
can then be posted to UseNet or e-mailed. Ditto for sound samples,
using the ideas I just described (but typically requiring sound
sampling boards, etc.). I've done some experiments along these lines.

This doesn't mean our problems are solved, of course. Exchanging tapes
is cumbersome and vulnerable to stings. But it does help to point out
the utter futility of trying to stop the flow of bits.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 27 Oct 92 19:45:14 PPE
To: cypherpunks@toad.com
Subject: re: Hackers Conference--Crypto Session
Message-ID: <3344.2AEDFD5B@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: tcmay@netcom.com (Timothy C. May)
 U> asked me to help put together the crypto session at the 
 U> Conference next week (6-8 November, Lake Tahoe). I of 

I consider it my job in the email world yto point out that the real
problems are not technical, but social, and a discussion of
privacy/crypto without underlying social stuff (how we interact, legal
issues like liability, etc) will devolve into technophilia. 

Yes I'm volunteering. I'll write something up before Hackers.

--- ReadMail
 * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 27 Oct 92 23:23:28 PPE
To: cypherpunks@toad.com
Subject: One-time pads and DC Nets
Message-ID: <9210280620.AA04910@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain




"Nobody" writes about the dining cryptographers protocol.

We talked about it at length at our first face-to-face meeting, but
the subject has barely come up on this list. People should read the
Chaum articles in the handout, and the excellent tutorial by Jurgen
Bos, also in the handout. It is truly exciting stuff, much more so
than the usual "classical cryptography" that we mostly talk about here
on this list.

Part of my great concern about the public key registration proposal is
that it will, if enforced, kill off many of these approaches that rely
on dynamically changing keys and digital pseudonyms.

If there's interest out there in the DC Net approach that "Nobody" so
nicely summarized, I'll forward some articles I wrote a while back for
another list.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Tue, 27 Oct 92 22:34:58 PPE
To: gnu@cygnus.com
Subject: D-H telnet protocol
In-Reply-To: <9210280200.AA24003@cygnus.com>
Message-ID: <9210280519.AA17075@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: gnu@cygnus.com

>As I said before, you're free to take what I come up with and add
>authentication.  But stop berating me in public for doing something
>to further the use of cryptography.

I'm not berating. I'm just suggesting.

I understand your reasoning about not wanting users to need to do any
administration, and I also understand your desire to do something good
for the crypto community. I will not argue that its a bad thing. The
only provisio I make is that it is SO easy to spoof exponential key
exchange that I'd argue that providing authentication is crucial if
people aren't going to be lulled into a false sense of security.

Perry





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 28 Oct 92 18:24:57 PPE
To: cypherpunks@toad.com
Subject: (fwd) Registering "Assault Keys"
Message-ID: <9210290008.AA29345@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Cypherpunks,

Things have gotten truly exciting. The posting I made alerting
sci.crypt readers to the plans of the Crypto Establishment has
generated something close to a hundred responses! And lots of private
mail for me (moral support, questions, etc.).

Dorothy Denning, in what writer correctly called a "spirited defense"
of her proposal, acknowledged the truth of my posting and then went on
to embellish her plan. I urge you all to read her well-written
comments, if only to see how the Establishment views crypto
technology.

Several members of this list have also written cogent comments.

My latest article is included below, for those of you who may not have
Net access.


Newsgroups: sci.crypt,comp.org.eff.talk,alt.privacy,talk.politics.guns
Path: netcom.com!tcmay
From: tcmay@netcom.com (Timothy C. May)
Subject: Registering "Assault Keys"
Message-ID: <1992Oct28.235027.28039@netcom.com>
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
X-Newsreader: Tin 1.1 PL5
Date: Wed, 28 Oct 1992 23:50:27 GMT


Registering "Assault Keys" -- How the Proposal to Register Encryption
Keys Has Ominous Parallels to Gun Control


The recent proposal that encryption keys be registered with the
government has some natural and terrifying implications. (For those to
whom this proposal is new, strange, or disturbing, please see the
debate raging mainly in the newsgroup "sci.crypt".)

Once the principle is established that private communications,
letters, faxes, modem transmissions, etc. must be in a form
readable--under court order, as Dorothy Denning's proposal goes--by
the government, and that "public key encryption" keys must be
registered with the authorities, then we can expect the following:

* _Classes_ of encryption keys, with some especially strong (in a
cryptograhic sense) keys being declared "assault keys," just as
certain classes of semiautomatic rifles have been branded "assault
weapons" and subjected to media villification and even confiscation by
the authorities. In analogy with firearms, there may be "Class 1"
dealers in "dangerous" keys.

* There may even be _bans_ on the registration (and hence use) of
certain classes of algorithms and key lengths. For example,
"civilians" may be allowed to use DES, but not RSA. Or the key length
may be restricted in various ways.

* Strict controls over the types of algorithms allowed. After all,
what use will a key be if the government can't run the algorithm?
This, by the way, will be another way to control the spread of
encryption technology: if only licensed, inspected, and approved
algorithms are acceptable to the key registration authorities,
innovation and experimentation will suffer. This may make RSA Data
Security, Inc., very happy, as it may get the "franchise," while users
of bootleg/contraband/experimental algorithms like PGP 2.0 ("Pretty
Good Privacy") face severe sanctions.

* Spot checks will have to be done to ensure compliance. This may be
done in various ways, such as by randomly checking bitstreams and
demanding the sender open the message. (Note: Many have posted that
this would not be possible. Untrue. The Rehnquist Supreme Court ruled
a couple of years ago that the police could enter a bus and ask the
passengers to "voluntarily" accept a search of their baggage. Failure
to volunteer, so reasoned the court, constituted probable cause for a
search! "Catch-22" meets "1984.")

* The penalties for noncompliance, or for hiding encrypted messages
inside other messages, will likely be severe, else widespread civil
disobedience and claims of "ignorance" will result. (Personally, I
_expect_ widespread noncompliance. Many people will even flaunt their
noncompliance, encrypting truly innocuous messages that few courts,
they will hope, will convict them for. Here in California, the
noncompliance rate for registration of those evil "assault weapons" is
estimated to be as high as 80%.)

(My best guess is that the "RICO" (Racketeer-Influenced and Corrupt
Organizations Act) and civil forfeiture approaches will be used to
simply seize the equipment of anyonone caught sending messages without
the suitable seals of approval. Such seizures, used with suspected gun
sellers, suspected X-rated video sellers, suspected drug dealers. and
so on, have had a profoundly chilling effect.)

* A registration system, even if well-intentioned and secured against
casual government snooping (and some of the multi-party escrow systems
may help do this), will still _greatly complicate_ the use of encryption
and will forestall certain very exciting applications of cryptology.
Many of the new proposals, for things like anonymous credentials to
protect privacy, for digital cash, and for cryptographic voting
systems, essentially require the _dynamic_ generation of keys! That
is, keys are generated frequently as part of the protocols...there is
not single static "public key" that one generates once and then takes
down to the crypto equivalent of the DMV for registration.

* As with guns, true criminals will of course ignore these laws.
Computer networks are already being used for messages that evade
wiretaps (as one example, a Mafia guy in New Jersey, on the run, used a
well-known computer service to communicate untraceably with his wife),
that are used for laundering information and money, and so on. Taking
encryption away from citizens will do nothing.


I urge readers to get involved in this debate.


"If encryption is outlawed, only outlaws--and the NSA--will have encryption."



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 28 Oct 92 19:42:40 PPE
To: cypherpunks@toad.com
Subject: National Security Agency
Message-ID: <9210290239.AA08764@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks of the world, encrypt!

Enclosed below is a posting I made to debunk Denning's claim that the
proposed key registration is needed to thwart criminals.

P.S. I still need more comments on how the Hackers session on crypto
should go. I've gotten some good private e-mail, but little debate
here on the list itself.

--Tim


Newsgroups: sci.crypt,comp.org.eff.talk,alt.conspiracy
Path: netcom.com!tcmay
From: tcmay@netcom.com (Timothy C. May)
Subject: Re: A Trial Balloon on Registered Keys
Message-ID: <1992Oct29.022842.8177@netcom.com>
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
X-Newsreader: Tin 1.1 PL5
References: <1992Oct28.214920.15601@tessi.com>
Date: Thu, 29 Oct 1992 02:28:42 GMT

Some comments about the National Security Agency (NSA) and why it
wants to restrict wide use of encryption.

George Mitchell (george@tessi.com) wrote:

: Now it's my turn to go out on a limb.  I believe that all the parti-
: cipants in this discussion would agree that: When the Government
: can show, through legitimately obtained evidence, that a particular
: encrypted communication relates to a crime, then they can, after
: the fact, subpoena the plaintext of that communication.  What
: most of us object to is having to yield the keys before the fact.

Agreed. The current procedure for subpoenaing documents works fairly
well.

But Prof. Denning's comments clearly indicate the concern is with
catching terrorists, kidnappers, subversives, and other such types _in
the planning stage_. That is, wiretapping and surveillance.

And I'll got out on a limb, too. My suspicion, and that of many
others, is that the case of the FBI catching terrorists before the act
in the U.S. (and there's a well-known case of a Japanese Red Army
terrorist caught in the Midwest several years ago) reveals the sources
the FBI uses. The NSA is the likely source. Only the NSA listening in
on millions of telephone conversations (not banned by any law...the
laws you hear about on wiretapping and surveillance mostly deal with
the FBI, law enforcement, and, supposedly, the CIA. The NSA is almost
completely exempt from such laws.).

If you haven't yet read James Bamford's "The Puzzle Palace," run out
and get a copy and read it. You'll see why former DIRNSA General Odom
called Bamford "an unindicted felon." (Why in the eyes of the National
Security Establishment, that is.)

SIGINT OPERATION MINARET, begun in 1969 when Nixon declared the "War
on Drugs," brought the NSA together with the FBI, CIA, BNDD (Bureau of
Narcotics and Dangerous Drugs, precursor to DEA) to launch a series of
new surveillance programs. In May 1970 the NSA extended routine
surveillance to _pay phones_ in suspect areas (sound familiar, with
the Digital Telephony Bill?). The release of the Pentagon Papers in
1971 revealed the extent of FBI and NSA elsur (electronic
surveillance) on U.S. citizens.

OPERATION SHAMROCK goes back even further. Beginning in 1945, the FBI
and NSA (its precursors, actually, such as Army Signal Corps, etc.)
cooperated to monitor dissidents, radicals, authors, etc. It was not
until October 1973 that about-to-be-fired Attorney General Elliot
Richardson (now fighting for INSLAW in a very similar case, which
Prof. Denning ought to read about) ordered the FBI and the CIA's
"Security Service" (aptly named SS) to stop requesting NSA
surveillance material. In 1977 the Justice Department recommended
against prosecution of the FBI and NSA employees engaged in Shamrock
and Minaret.

Few Americans understand how pervasive is the NSA's listening system.
COINTELPRO, Huston Plan, RCA Global (provided copied of all telegrams
for 40 years!), FINCEN, and so many other keywords! Huge antennas in
West Virginia, in Idaho, and elsewhere (mostly located near major
satellite downlinks). Read Bamford's book. Then be afraid....be _very_
afraid.

Understand that there are virtually no laws governing the NSA's
surveillance of fax machines, modems, the Internet (including all of
these postings, obviously), voice phones, telex and TWX, and on and
on. Because of the "national security" role, wide lattitude is given. 

No doubt some criminal plans are uncovered. The NSA detected, it has
been admitted, the planned bombing of the Berlin discotheque that led to
the '86 raid on Libya. (However, the bombing still occurred...draw your
own conclusions.) But is it worth the price?

Now there is talk of using the NSA's formidable listening abilities
for economic espionage against our economic opponents! 

Is it any wonder the NSA is scared sh..less over the spread of secure
and untappable communications systems?

Be afraid, be _very_ afraid.
-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Thu, 29 Oct 92 01:33:13 PPE
To: cypherpunks@toad.com
Subject: speaking of data on music CD's
Message-ID: <9210290832.AA21734@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



speaking of messages that can be passwd on musical CD's,  I thought
this might be of some amusement

		    -Pete

------- Forwarded Message

Return-Path: cambler@nike.calpoly.edu
Received: by ts2.TFS.COM (5.51/1.00 (TRP - mailsrv))
	id AA27917; Tue, 27 Oct 92 03:00:31 PST
Received: from zeus.calpoly.edu by tfs.COM (5.61/1.00 (TRP - gateway))
	id AA04680; Tue, 27 Oct 92 03:00:21 -0800
Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0)
	id AA167170; Tue, 27 Oct 92 03:00:19 -0800
Date: Tue, 27 Oct 92 03:00:19 -0800
From: cambler@nike.calpoly.edu (Christopher J. Ambler, Phish)
Message-Id: <9210271100.AA167170@nike.calpoly.edu>
To: shipley
Subject: Re: laser

Here, check this out:


Okay, here's the scoop. At the end of the new Information Society CD,
there's a 3 minute track (track 12) that's called "300BPS N81" ... Well,
I was curious, so I hooked the thing up to a phone line here, tied my
modem's carrier detect high, and played with the gain. After 4 or 5
tries, THIS IS WHAT I GOT.

- --- begin

ath1
OK
ato
CONNECT 300
 
  SO WE'RE SUPPOSED TO PLAY IN CURITIBA IN 18 HOURS, BUT OUR BUS IS BEING HELD
HOSTAGE BY THE LOCAL PROMOTERS. THEY'VE FORMED SOME UNHOLY ALLIANCE WITH THE
BRAZILIAN COUNTERPART OF ASCAP; THE PRS. APPARANTLY THE PRS HAS THE LEGAL POWER
TO ARREST PEOPLE, AND THEY WANT A PIECE OF THE NATIONAL TOUR PROMOTER'S MONEY. 
THE LOCAL SECURITY FORCE, "GANG MEXICANA", HAS BEEN BOUGHT OUT FOR 1800 
CRUZADOS AND A CARTON OF MARLBOROS EACH. THE ONLY FACTION STILL OPERATING IN
OUR DEFENSE IN "BIG JOHN", OUR PERSONAL SECURITY MAN, AND HE'S HIDING IN HIS
ROOM BECAUSE A LOCAL GANG IS OUT FOR HIS BLOOD BECAUSE OF A 1982 KNIFING
INCIDENT IN WHICH HE WAS INVOLVED. OUR 345-POUND ROAD MANAGER, RICK ONLY HAD
THIS TO SAY: "YOU WANTED THE LIFE OF A ROCK STAR!". PAUL, JIM AND I REALIZED
THAT THIS WAS ONE SITUATION WE WERE GOING TO HAVE TO GET OUT OF OURSELVES.
  WE CONVENED A HASTY CONFERENCE IN THE NOVOTEL LOBBY. PAUL SUGGESTED CONTACT-
ING OUR NATIONAL TOUR PROMOTER IN SAO PAULO, BUT WE REMEMBERED THAT HE WAS IN 
RECIFE WITH FAITH NO MORE, WHO HAD JUST ARRIVED FOR THEIR BRAZILIAN TOUR. WE 
THOUGHT ABOUT CONTACTING OUR BRAZILIAN RECORD COMPANY IN RIO, BUT THEY WEREN'T
HOME. OUR EVER-DILIGENT AMERICAN MANAGER WAS ARRANGING HELP OF NUMEROUS FORMS,
BUT HE WAS IN NEW YORK, AND JUST TOO FAR AWAY TO GET ANYTHING MOVING IN TIME.
  
  AND THERE WERE 6000 KIDS IN CURITIBA WHO JUST WOULDN'T UNDERSTAND.
  
  WE KNEW IT WAS TIME FOR ACTION. PAUL WENT UP TO THE PRS GUYS AND INVITED 
THEM INTO THE BAR TO DISCUSS IT LIKE CIVILIZED MEN OVER A FEW BRAZILIAN DRINKS,
OFFERING EACH OF THEM A CIGAR ON HIS WAY. THE AMUSED PRS HEAVIES SEEMED TO 
LIKE THE IDEA OF A FEW FREE DRINKS, EVEN IF THEY KNEW THEY WOULD NEVER GIVE 
US OUR BUS BACK. WHEN PAUL WINKED AT JIM AND I ON HIS WAY IN, WE WENT INTO 
ACTION.
  I STOLE OFF TO MY ROOM TO PREPARE WHILE JIM WENT INTO ACTION. CREEPING
CAREFULLY THROUGH A SERVICE DUCT, HE MANAGED TO GAIN A VANTAGE POINT SOME
THREE METERS ABOVE THE BUS, AND DROPPED CAREFULLY ONTO THE ROOF. AFTER USING
HIS ALL-PURPOSE SWISS ARMY KNIFE (AFFECTIONATELY KNOWN AS THE "SKIT KNIFE")
TO JIMMY OPEN THE ROOF HATCH, HE WENT THROUGH THE DARKENED INSIDE OF THE BUS
AND REMOVED THE INSIDE ENGINE SERVICE PANEL. USING SOME SPARE ELECTRONIC PARTS 
HE FOUND WHILE ON AN ISLAND IN THE AMAZON, HE WIRED THE ENTIRE BUS FOR REMOTE 
CONTROL, NOT UNLIKE A REMOTE CONTROL TOY CAR.
  AT THIS POINT, HE ASKED HIMSELF "NOW HOW SHALL I GET OUT OF HERE?!?"
  PAUL WAS HAVING DIFFICULTIES OF HIS OWN.
  "COULDN'T YOU SEE YOUR WAY CLEAR TO LETTING US FULFILL OUR CONTRACTUAL 
OBLIGATIONS IN CURITIBA? THINK OF THE KIDS!"
  THROUGH OUR TRANSLATOR, FABIO, THE PRS MAN, ALDO, SAID;
  "NO. YOU AMERICANS THINK YOU OWN THE WORLD. HAH! WE'LL BURN DOWN OUR RAIN
FOREST IF WE DAMN WELL PLEASE. WE NEED ROOM FOR COWS!! WE WANT A MACDONALD'S ON
EVERY... OH, SORRY, YES ANYWAY, NO. WE NEED 40% OF YOUR CONCERT RECEIPTS TO
GIVE TO DAVID BOWIE." HE SAID, WINKING TO THE LOCAL PROMOTER, PHILLIPE.
  AS PAUL CONTINUED THIS ELABORATE DISTRACTION, JIM EFFECTED AN ESCAPE FROM 
THE HEAVILY GUARDED BUS BY CRAWLING DOWN INTO THE CARGO BAY, CUTTING A HOLE 
IN THE FLOOR WITH THE SWISS ARMY KNIFE'S ARC-WELDER, SLIPPING INTO THE MANHOLE 
COVER SITUATED UNDER THE BUS, AND WALKING UP INTO THE HOTEL'S BASEMENT FROM 
THERE. JIM CALLED UP TO ME IN MY ROOM AND GAVE THE SIGNAL. WE WERE NOW TO MEET
AT THE BACK ENTRANCE, WITH OUR TECH GUYS. BUT FIRST, PAUL WOULD NEED SOME HELP
GETTING AWAY FROM HIS UNWELCOME GUESTS, AS THINGS WERE GETTING UGLY.
  "HE SAYS HE HAS LOST HIS PATIENCE, AND THAT HE CAN THINK OF OTHER WAYS OF
EXACTING PAYMENT FROM YOU KURT AND JIM PHYSICALLY." OUR TREMBLING INTERPRETER
SAID.
  THE MOMENT HAD COME. JIM BEGAN OPERATING THE BUS FROM HIS BACK ENTRANCE
VANTAGE POINT. AS THE REMOTE-CONTROLLED BUS LURCHED TOWARDS THE PARKING LOT 
EXIT, THE SUPERSTITIOUS SECURITY YOUTHS FLED IN TERROR. PAUL WAS PULLING 
ANXIOUSLY ON HIS COLLAR AS THE PRS MAN BEGAN DESCRIBING HIS COLLECTION OF 
WORLD WAR II NAZI CERIMONIAL KNIVES WHEN A SUDDEN CRASH SPLIT THE TABLEAU.
  JIM HAD PURCHASED ME THE GIFT OF A COMPLETE BLACK NINJA STEALTH ASSASSIN
OUTFIT IN ARACAJU. I HAD BEEN GEARING UP AND CRAWLING THROUGH THE AIR 
CONDITIONING DUCTS ALL THIS TIME. AS I CRASHED THROUGH THE CHEAP IMITAION-
STYROFOAM HUNG CEILING TILES, SKATES FIRST, I FLASHED NINJA STARS ALL ABOUT ME.
IN THE ENSUING PANIC, PAUL ESCAPED TO THE PRE-ARRANGED BUS PICK-UP POINT.
UNFORTUNATLEY, MY SKATES WERE A POOR CHOICE OF FOOT GEAR FOR ESCAPING OVER THE
BROKEN GLASS. OF THE TABLE I HAD LANDED ON. WERE IT NOT FOR THE CONFUSION AND 
THE NINJA-STAR-INFLICTED WOUNDS DELIVERED TO THE BAD GUYS, I WOULD HAVE BEEN 
SET UPON WHILE FOUNDERING ON THE GLASS-STREWN CARPET. AS IT HAPPENED, HOWEVER,
I LEAPT THROUGH THE OPEN DOOR OF THE CAREENING BUS AS IT DEPARTED THE CITY OF 
MARINGA FOREVER.
 
  IF ONLY WE HAD MANAGED TO GET OUR EQUIPMENT IN THE BUS, TOO . . . 
 
  EVERY WORD OF THIS STORY IS TRUE.
                                     - KURT HARLAND}
NO CARRIER

------- End of Forwarded Message





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
Date: Thu, 29 Oct 92 14:26:42 PPE
To: cypherpunks@toad.com
Subject: drugs for sale
Message-ID: <3373.2AF03157@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



A cross posting from FidoNet PUBLIC_KEYS. It would be nice if some
other cypherpunks could join the PUBLIC_KEYS echo. 



;Date      29 Oct 92  11:28:07
From:      Jesse David Hollington@1:125/33
To:        Arol Ambler@1:125/111
Subject:   Test
>----------------------- Do not change this line -----------------------------<
 AA> Anyway, anyone who is concerned can always use some method that hides the 
 AA> fact that any secret content is even being communicated.  (Variations on 
 AA> read every fifth word to see the real message, or other standard 
 AA> methods).

 It's funny you should bring that up.  One of the major proponents of 
encryption here in Region 12 posted the following in the Regional Sysop Echo 
some time ago... 

=============================================================================

Having said that, I also wonder whether this insistence upon having
everything in plain text isn't fostered by some sysops as a means of
receiving information that they otherwise wouldn't be privy to. If
one is truly paranoid ( *not* that I would fall into that category 
in anyone's wildest dreams...ahem), one should worry about why some
netmail is read so assiduosly by passthrough systems in the first place.
 
Fortunately, even mail that I send direct to nodes is quoted back and
often passes through a whole variety of systems for their inspection and
review.
 
Since almost all of my netmail is incredibly innocent there might
always be the possibility that some of it will come back to hover
like a bad dream in some creative complaint. In broader legal terms,
every other communication system avoids eavesdropping on mail.
 
 
P.S. To understand how powerless you  are to prevent encrypted text, read 
the leftmost letter of each sentence in the last three paragraghs 
downwards...ahem.
 
===========================================================================

 He raises a valid point.  Sysops who are so paranoid about encrypted mail 
being sent through their systems should realize that they are really powerless 
to prevent it if somebody is determined enough to send a coded message to 
somebody else.  

 I've sought legal opinions in Canadian law (I don't know how it is in the 
U.S.) and I've discovered that the less I know about mail passing through my 
system, the safer I am.  If I keep every message on my system, and read them 
all, then I can be held liable if somebody routes something illegal through my 
system and it slips by me.  If I kill all passthrough mail, and read nothing 
except what is addressed to me, I am operating under common carrier status, 
and can't be held liable any more than Federal Express or UPS could.

 As a result, it's actually better to *encourage* people to send encrypted 
mail through your system.  The belief that if people are sending encrypted 
mail they're doing something wrong is a fallacy... then again, I'm preaching 
to the converted here.

Cheers,
 Jesse.


--- Maximus 2.01wb
 * Origin: On a Clear Disk You Can Seek Forever (1:225/1)
--  
tom jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET: tom.jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Wed, 28 Oct 92 18:09:15 PPE
To: cypherpunks@toad.com
Subject: How far would this extend...
Message-ID: <9210290109.AA29045@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


With regard to the FBI bill, the definition of electronic communication
provider is rather vague IMHO. It seems to cover a BBS, any unix site
(or equiv) etc.

(I deleted the article so I cant quote it)

Anyway if the above is true will this mean all machines that electronic
communication traverses have to have a 'backdoor' so the gov can sit in
their offices and run through the mail spool as root? :)

Or log into any BBS and do the same?

There hasnt been any talk of it as such, probably because they can do it
fairly easily anyhow, but it just seems like another loophole in their
(the FBI's) favour.

_Sometimes_ I'm glad Im an aussie.

Mark




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Fri, 30 Oct 92 12:02:40 PPE
To: cypherpunks@toad.com
Subject: Subscribe
Message-ID: <iykFTB5w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


I got this address off Extropians. Sorry if there's a separate
"request" address I should be using, but I don't know what it is.
 
Please add me to your mailing list.
 
Please use one of these addresses:
 
               Internet: edgar@spectrx.saigon.com
                   UUCP: szebra!spectrx!edgar
 
The address in the network header may not work.
 
I'm familiar with how PGP 2.0 works, including some bugs. I'm trying
to start a low-cost public key registry, which can verify public
keys independent of the network.
 
Here is my signed 512-bit public key:
 
-----Type bits/keyID   Date       User ID
-----pub   512/4F0C47 1992/09/26  Edgar W. Swank <edgar@spectrx.saigon.com>
-----sig!      67F70B 1992/10/14    Philip R. Zimmermann 
<prz@sage.cgd.ucar.edu>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.02
 
mQBNAirEvxwAAAECAMUkLHrx6JH45BMd4bxZDNQO3HrLmhZSvsHJzLH9+90BTbuX
3Kvo0pSLCh98m2Abu/LtoHDggJOKxRGee+5PDEcABRG0KUVkZ2FyIFcuIFN3YW5r
IDxlZGdhckBzcGVjdHJ4LnNhaWdvbi5jb20+iQCVAgUQKtu1h+J13g7/Z/cLAQFg
nAQAjRlKmmSvDMZUWKM2BQFmpqHBiaCg7OLKEFng9pZGx2qzYHCZOL+a9A0exN9P
RAtV6bEm9+F8VoOEpVyF346XJwwE1e/13IETHFi7Jd9fbjsw8voQFqz69X2p8xoE
LxYtqSlwfOQ3S7JOyyx4/p04fG/JZuRJicVaUIRlDKHJPJ0=
=tsbS
-----END PGP PUBLIC KEY BLOCK-----

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tomj@f111.n125.z1.FIDONET.ORG (tomj)
Date: Fri, 30 Oct 92 02:00:19 PPE
To: cypherpunks@toad.com
Subject: PUBLIC_KEYS pre-Backbone topology
Message-ID: <3383.2AF0F94F@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Here's a nerd message from PUBLIC_KEYS echo conference showing
activity and growth. This conference has been around about three
weeks.


GLOSSARY:

        node            host
        conference      newsgroup
        echo            newsgroup
        message         article
        1:222/333       FidoNet address (ie. host site address)
        backbone        a somewhat formal high-throughput systems
                        that carry a large proportion of echos. 
                        Only very popular echos are carried on the backbone;
                        low traffic ones the member sites deliver their
                        own mail (we don't ahve corp. sugardaddies like
                        most internet/uucp sites, I pay Pac Bell each month...)


The hideous unreadable gunk is a sort of 'traceroute' of generated
message traffic during some period of time, and tends to show the
topology. Echomail is a completely distributed, redundant database.
Moderation is not physically possible (there is a thing called
groupmail that is, but we're not using it). It shows who connects to
whom. There is at least one human reader/poster at each node (the
sysop); my guess would be about 1.5 average for this subject.



Why did I mail this to cypherpunks list? To show the amount of
interest in PGP, and demystify FidoNet somewhat.






here's the current report from msgs posted here:
 
PATHS: Maintain and report PATHS a message takes within an echo
       Copyright (C) 1991, Graham J Stair. All rights reserved.
       Release 1b for DOS (16th June 1991, 15:59) {-? for help}
 
Message directory   :  \msg\pkey\
Checked on          :  Sat Oct 24 18:13:40 1992
 
Number of nodes     :  53
Number of messages  :  778
Earliest message    :  Sat Oct 03 20:04:12 1992
Latest message      :  Sat Oct 24 17:06:42 1992
Messages per week   :  260.9
 
1:374/14  (180 of 774)
  |-}1:374/26  (44 of 53)
  |    |-}1:322/603  (5 of 5)
  |    |-}1:374/12  (1 of 1)
  |    |-}322/6  (4 of 4)
  |-}1:216/21  (32 of 53)
  |    |-}216/80  (0 of 21)
  |         |-}273/219  (0 of 3)
  |         |    |-}1:273/219.4  (1 of 1)
  |         |    |-}1:273/937  (1 of 1)
  |         |    |-}1:273/219.1  (1 of 1)
  |         |-}1:143/269  (18 of 18)
  |-}1:374/98  (3 of 6)
  |    |-}1:374/46  (3 of 3)
  |-}1:100/520  (11 of 11)
  |-}1:285/27  (26 of 44)
  |    |-}30102/20  (18 of 18)
  |-}1:170/109  (18 of 18)
  |-}1:105/36  (20 of 39)
  |    |-}1:105/68  (6 of 6)
  |    |-}1:105/290  (13 of 13)
  |-}135/71  (0 of 19)
  |    |-}1:135/907  (19 of 19)
  |-}1:396/1  (5 of 8)
  |    |-}203/23  (0 of 2)
  |    |    |-}125/125  (0 of 20)
  |    |         |-}125/20  (0 of 11)
  |    |         |    |-}1:125/209  (8 of 8)
  |    |         |    |-}1:125/54  (3 of 3)
  |    |         |-}1:125/33  (1 of 9)
  |    |              |-}1:308/60  (8 of 8)
  |    |-}109/25  (0 of 1)
  |         |-}1:2601/100  (1 of 1)
  |-}1:234/1  (40 of 40)
  |-}1:377/14  (56 of 78)
  |    |-}1:377/3  (19 of 19)
  |    |-}377/15  (0 of 2)
  |    |    |-}1:377/15.1  (2 of 2)
  |    |-}1:377/33  (1 of 1)
  |-}163/438  (3 of 9)
  |    |-}1:163/518  (3 of 3)
  |    |-}1:243/3  (3 of 3)
  |-}1:125/180  (54 of 112)
  |    |-}1:125/111  (38 of 38)
  |    |-}1:125/185  (2 of 2)
  |-}1:2200/101  (2 of 2)
  |-}1:135/340  (52 of 52)
  |-}1:312/2  (16 of 16)
  |-}1:106/7550  (33 of 33)
  |-}2:253/513  (2 of 2)
  |-}1:261/1136  (1 of 1)
  |-}374/92  (0 of 1)
       |-}374/13  (0 of 1)
 
 
Notes:
If a node does not appear in this report, it could mean...
   a) It did not have a message entered from it.
   b) It did not have a message pass through it to get to the top node.
   c) Its mail processor doesn't update the ^APATH: kludge with its address.
If any feeds change, the report will be unreliable.
 
[converted from high ASCII lines to low ASCII characters by CONV004.ZIP]
 
-30-
 
if we show up in FIDONET.NA tomorrow, everyone stand-by to switch over
to Backbone feeds. this ALWAYS take a couple weeks to settle down. cut
your direct links as soon as you get confirmation of link from your
Backbone source. if you don't get confirmation first, you will
probably miss traffic as the Backbone doesn't do rescans. we will get
a few dupes. this is inevitable with a private to Backbone changeover
and no one should get excited about it.  just be sure to pull your
direct plug as soon as traffic flows from your Backbone source or you
get confirmation of feed, whichever comes first.  

thanks.
 
TTFN.
Chris

--- DB 1.50/001027
 * Origin: Rights On! - Privacy #1 Right! - Titusville_FL_USA (1:374/14)
SEEN-BY: 106/1555 109/25 124/1 125/20 28 33 111 125 180 185 1212 170/610 203/1
SEEN-BY: 203/23 205/10 209/209 374/14 396/1
;;;
--  
tomj - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tomj
INTERNET: tomj@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Fri, 30 Oct 92 15:53:14 PPE
To: cypherpunks@toad.com
Subject: Copies of Crypt Handout and RSA FAQ
Message-ID: <9210302035.AA20939@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Some people on this list picked up on my mention of the 60-page
handout distributed at our first meeting (9-19-92) and have asked
about getting copies.

I've distributed all the copies I made before, but may be willing to
make more. The problem is cost and time: each copy costs me about
$2.00 and there are more than 100 people on this list. Any ideas?

I also have a fresh copy of RSA's 52-page FAQ (which is also available
by ftp, but many folks have had problems printing it). The same
calculation applies.

Whatever the solution, I will only make one "copy run," as I don't
want to be a document distribution service on a continuing basis.
Until a solution appears, PLEASE DO NOT SEND ME REQUESTS, MONEY, ETC.

BTW, this applies to PGP 2.0 diskettes as well. I just mailed a
diskette to someone who'd been unable to get the ftp'ed version. (And
my diskette came from someone on this list, too...thanks!) I didn't
ask for postage or diskette fees, but I clearly can't do this with
dozens of folks. And yet it seems we ought to find a way to do this.

One idea is to put our ideas into practice by having some kind of
"escrow service" which holds deposited money (small amounts, given the
items discussed here) and which can be used to buy small items, with
payments handled electronically (ultimately settled with actual
checks, of course). This could get out of hand, of course, so it's
just an idea. Any comments?

P.S. And don't forget to make your suggestions on the Crypto session
at Hackers. I'll be issuing a status report soon.

--Tim
-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Fri, 30 Oct 92 15:23:43 PPE
To: cypherpunks@toad.com
Subject: Why I Don't Use PGP
Message-ID: <9210302106.AA22149@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Why I Don't Use PGP -- The Top 10 Reasons (from the David Lettercrypt
Show)

(...drum roll...)

10. Because I use a Mac and the Mac version is not out yet.

9. Because the Mac version may NEVER be out.

8. Because my old IBM PC won't read the 3.5" diskettes my Mac puts
out.

7. Because downloading encrypted files with ZMODEM, writing them to
DOS format (with Apple File Exchange), hauling out my Toshiba 1000SE
laptop and firing it up, loading the 3.5" diskette, and then running
PGP takes 5 minutes per message.

6. Because after doing all of the above, I usually get "This is not a
PGP file," due to some obscure mistranslation somewhere along the way.

5. Because I barely have the time to read and respond to my ordinary
e-mail, let alone decrypt mail, respond (on my DOS machine), and then
reverse the above procedure.

4. Because I'm not yet convinced it is needed. It will be someday, but
not for right now. (Getting PGP volume up is a great idea...it's the
actual decryption that's a pain. Maybe we ought to send dummy
messages.)

3. Because ideally our mailers should handle this in a push-button way
(I know about the security flaws in having a nonlocal host machine,
such as my NETCOM host, do the PGP procedure...I am hoping that
someone will write something that transparently "reaches down" into my
machine and triggers the computation locally on my machine--and I need
a Mac version, of course. Probably an off-line Newsreader for the Mac,
like Nuntius, is needed.)

2. Because I don't give out my PGP key (generated on my Toshiba) to
all of those who have e-mailed me about it (especially in the wake of
my postings about the Denning proposal). The last thing I want is more
e-mail from people I've never met, sending me their encrypted secrets
of the universe.

(...and the Number One reason I don't use PGP?.....)

1. Because computers were supposed to make my life easier, and they
haven't. 

Well, that's enough reasons. I guess I'm just lazy, or have higher
priorities than to spend 5 frustrating minutes per mail message.
Ironically, I'm not alone. I have heard that even Phil Zimmerman lets
his PGP-encrypted messages pile up in his incoming mail, due to the
hassles.

As Eric Hughes has noted, it is precisely this pain that will cause
improvements to be made.


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Andrew Purshottam <andy@autodesk.com>
Date: Fri, 30 Oct 92 17:50:53 PPE
To: cypherpunks@toad.com
Subject: Re: remove from mailing list
In-Reply-To: <9210242237.aa22143@src4src.linet.org>
Message-ID: <9210302349.AA01575@meefun.YP.acad>
MIME-Version: 1.0
Content-Type: text/plain


Are you Jethroes still using berkeley mail? Get a real mail user
agent, like MH, and you can write a pattern that collects all the mail
sent to a given address into a mail folder, effectively making your
own digest.

Andy








From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Fri, 30 Oct 92 20:46:23 PPE
To: cypherpunks@toad.com
Subject: re: Why I Don't Use PGP
Message-ID: <3394.2AF2012B@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: tcmay@netcom.com (Timothy C. May)

 U> 10. Because I use a Mac and the Mac version is not out yet.

I'll ask in the FidoNet PUBLIC_KEYS echo about Smackintoshes.

 U> 9. Because the Mac version may NEVER be out.

... prolly cuz noone can figger out how to make a lot of money from
it! 

 U> 4. Because I'm not yet convinced it is needed. 

Ayup. My feelings exackly. This is starting to sound just like my gun
arguments... I don't need one on the street, but someday I may, no?

 U> 3. Because ideally our mailers should handle this in a 
 U> push-button way 

Some do already...


--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems  (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sat, 31 Oct 92 03:45:42 PPE
To: tcmay@netcom.com
Subject: Re:  Why I Don't Use PGP
Message-ID: <199210311044.AA08180@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



Re. Ten Reasons Why I Don't Use PGP:

This is exactly why we need a decent user interface.  The ideal would be a
public-domain wordprocessor, which could be fairly simple, with a menu
option for encrypt/decrypt, signature, and so on.  I've been working on
something like this for my OTP, and would be glad to participate in a
project to do it for PGP and other systems.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 31 Oct 92 09:42:14 PPE
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Why I Don't Use PGP...
Message-ID: <921031163437_74076.1041_DHJ36-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


The best way to integrate PGP into other software is a tough
question.  There are so many different ways in which people read
and send mail.

A lot of people receive their mail on some other machine, often
a multi-user machine.  So, the first question is, should the mail
be crypted there, or should it be crypted on your personal machine.
The second choice is preferable from the security point of view,
but that means that you need to download at least your PGP mail
in order to decrypt it, and it means you have to compose your
mail on your home machine before encrypting, uploading, and sending.

(Phil Zimmermann had an idea for multi-user systems in which the
RSA portion of the decryption, which involves your secret key, would
be done on your personal machine, then the decrypted session key
would be uploaded to the multi-user machine and the IDEA decryption
done on the message itself.  This way you only have to upload and
download a couple hundred bytes regardless of the length of the
message.  This would require PGP to be integrated into a terminal
program.)

If you _do_ download your mail before reading it, you could get in
the habit of downloading _all_ of your mail into a big file, then
running a word processor or some more specialized program to
read the messages, one at a time, and compose replies.  Then, when
you were done, you could upload and send the replies.

If you worked in this mode, which probably few people do, you could
integrate PGP by running it on the downloaded mail file before running
your WP to read it.  I have a Perl script which runs PGP on a file,
finding the PGP messages in it, decrypting them, and replacing them
_in_the_file_ with their decrypted versions.  (Normally PGP outputs
its decrypted contents to another file, which is a little inconvenient.)
This can make PGP pretty transparent for decryption if you actually
read your mail in this way.

Another possibility is to use a WP or mail reading program which has
a "filter" mode, one which lets you pass incoming or outgoing mail
through some program, and replace the mail with the results of that
program.  I don't know which programs can do this.  A lot of Unix
programs can, like VI and EMACS, but I don't know about PC's or other
home machines.  PGP has a filter mode which is designed to be used with
WP's which can do this.  There have been a couple of messages on
alt.security.pgp which have advice on using PGP with various Unix mail
reading programs.  Mark Riordan's soon-to-be-released RIPEM program
(an alternative, incompatible, RSA public-key program) has some ideas
in its manual on how to use its filter mode with Unix mail, which mostly
apply to PGP as well.

One other point: regarding a Mac port: There have been at least a couple
of messages on alt.security.pgp over the past couple of months from
people who have successfully compiled the PGP sources under Think C
on the Mac.  However, as a Unix/PC program, it ends up using a character
window for I/O, which you type into just like you would on a PC.
This is unacceptable for Macs, so nobody has released one of these.
Still, compared to what Tim has to do, it would be an improvement.  I
think people should release their executables which work like this as
an interim crutch version until the real Mac version is available.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sat, 31 Oct 92 13:31:32 PPE
To: cypherpunks@toad.com
Subject: re: Why I Don't Use PGP...
Message-ID: <3400.2AF2EC7B@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain




 U> From: 74076.1041@CompuServe.COM (Hal)

 U> The best way to integrate PGP into other software is a 
 U> tough
 U> question.  There are so many different ways in which 
 U> people read and send mail. 

 U> don't know which programs can do this.  A lot of Unix 
 U> programs can, like VI and EMACS, but I don't know about 
 U> PC's or other home machines.  PGP has a filter mode which 


Not to brag, but my offline-reader (DOS version of a 'read news'
program), as well as at least one other I know of, does a pretty good
job of this. It handles the decrypted plaintext reasonably securely
too. It does the decryption locally. (You have to manage your own
keyrings externally, though of course keys embedded in messages are
handled OK.)

Solutions are out there.


--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems  (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 31 Oct 92 13:45:38 PPE
To: cypherpunks@toad.com
Subject: re: Why I Don't Use PGP...
In-Reply-To: <3400.2AF2EC7B@fidogate.FIDONET.ORG>
Message-ID: <9210312042.AA02821@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Tom Jennings writes:

> Not to brag, but my offline-reader (DOS version of a 'read news'
> program), as well as at least one other I know of, does a pretty good
> job of this. It handles the decrypted plaintext reasonably securely
> too. It does the decryption locally. (You have to manage your own
> keyrings externally, though of course keys embedded in messages are
> handled OK.)
> 
> Solutions are out there.

I'm impressed. Maybe in 2-3 months this'll all shake out a bit, with a
Mac version (rumored to be in beta), more "push-button" PGP systems,
etc.

By the way, Tom has generously agreed to talk about PGP, mailers,
FidoNet, etc., at our Crypto session at Hackers. (I'll be sending out
a more complete status report soon.)

--Tim

(Also, I have changed the last line of my .sig to reflect my current
unwillingness to mail my PGP key to all of those who are asking for
it. Hopefully this will soon change.)


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 31 Oct 92 14:04:32 PPE
To: cypherpunks@toad.com
Subject: Re: Why I Don't Use PGP...
In-Reply-To: <921031163437_74076.1041_DHJ36-1@CompuServe.COM>
Message-ID: <9210312101.AA03883@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Hal Finney, Tom Jennings, Eric Hughes, and others are working on
solutions to the "ease of use" problems I cited in my posting.

Hal F. writes:

> The best way to integrate PGP into other software is a tough
> question.  There are so many different ways in which people read
> and send mail.

> If you _do_ download your mail before reading it, you could get in
> the habit of downloading _all_ of your mail into a big file, then
> running a word processor or some more specialized program to
> read the messages, one at a time, and compose replies.  Then, when
> you were done, you could upload and send the replies.
> 
> If you worked in this mode, which probably few people do, you could
> integrate PGP by running it on the downloaded mail file before running

This is a major drag, destroying the feedback loop of reading mail and
responding to it immediately. And, as Hal alludes to, it requires
extra stuff, like PERL scripts, which complicate matters.

> on the Mac.  However, as a Unix/PC program, it ends up using a character
> window for I/O, which you type into just like you would on a PC.
> This is unacceptable for Macs, so nobody has released one of these.
> Still, compared to what Tim has to do, it would be an improvement.  I
> think people should release their executables which work like this as
> an interim crutch version until the real Mac version is available.

Here's hoping. Several people claim to be working on a real Mac port.
(I thought the idea someone had of doing it inside a HyperCard stack
was a good one..HyperCard supports a CLI and so could run PGP, and
HyperCard newsreaders exist, so in perhaps the two could be united.)

Zimmerman's PGP has spurred people to think about the many practical
issues of P-K crypto...authentication systems, keyrings, user
interfaces, and so on. This alone is a major step forward.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Oren Mitz <oren@coma.huji.ac.il>
Date: Sat, 31 Oct 92 13:51:56 PPE
To: cypherpunks@toad.com
Subject: Please remove me from the mailing list!
Message-ID: <9211010151.AA18004@coma.huji.ac.il>
MIME-Version: 1.0
Content-Type: text/plain


Sorry, can't handle the numer of messages every day
.   Thankx and out.

  bye bye from O><M




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Sun, 1 Nov 92 13:03:32 PPE
To: MCGRATH@elec.canterbury.ac.nz
Subject: PGP vs RSA
In-Reply-To: <MAILQUEUE-101.921101152403.352@orpheus>
Message-ID: <9211011932.AA07699@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Jim McGrath <MCGRATH@elec.canterbury.ac.nz>

>The other day someone mentioned that PGP uses a patented algorithm. If this
>is the case, then what is the difference between using it and the also
>patented RSA. From the little reading that I have done, it sounds like RSA is
>a better protocol from the point of view of authentication etc. etc.

PGP does use RSA. Obviously the "little reading" that you have done
has been little indeed.

>So, the question is, apart from the fact that PGP exists, and an RSA
>implementation is not yet available, (to the best of my limited knowledge)
>is there any reason why we shouldn't use it?

There are dozens of RSA implementations available including PGP -- PGP
is, however, the only widely available one with its code in the public
domain. 

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Jim McGrath <MCGRATH@elec.canterbury.ac.nz>
Date: Sat, 31 Oct 92 19:24:20 PPE
To: cypherpunks@toad.com
Subject: PGP vs RSA
Message-ID: <MAILQUEUE-101.921101152403.352@orpheus>
MIME-Version: 1.0
Content-Type: text/plain


The other day someone mentioned that PGP uses a patented algorithm. If this
is the case, then what is the difference between using it and the also
patented RSA. From the little reading that I have done, it sounds like RSA is
a better protocol from the point of view of authentication etc. etc.

So, the question is, apart from the fact that PGP exists, and an RSA
implementation is not yet available, (to the best of my limited knowledge)
is there any reason why we shouldn't use it?

Jim McGrath

I'd rather have a bottle in front of me than a frontal lobotomy.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sun, 1 Nov 92 19:50:18 PPE
To: cypherpunks@toad.com
Subject: Public image...
Message-ID: <3410.2AF4969F@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Another crosspollination from PUBLIC_KEYS. Just something to think
about.

It refers to Keith Henson's article I ran in FidoNews (apparently the
file was corrupted, but that's another story.)

This is in no way to imply that the story is bad, nor that I didn't
like it (I did), nor that this is even a common opinion. I actually
received a few thanks for running it. It's just something to consider.
And implies that Keith's article/story is doing it's job!








A message from Tom Jennings to all was released into the bitstream 20 Oct 92  
12:51.

 TJ> re: PUBLIC RELATIONS, hell, substance too --

 TJ> If what we're doing here is ensuring PRIVACY, let's call it PRIVACY.
 TJ> Calling it encryption simply drops us into the same category as
 TJ> crackers and criminals.

 TJ> This isn't apologia; it's infowar. The "anti abortion" people calling
 TJ> themselves "pro life" is a good example (regardless of what you think
 TJ> of the subject, please, I don't want to know, not even in netmail!)
 TJ> Naming is powerful, especially when names have content. "PRIVACY" is
 TJ> age-old, and crosses all boundaries, and is inherently anti-statist.
 TJ> ENCRYPTION is cloak'n'dagger, late night movies, WWII, espionage, etc.

Speaking of which, the story by Keith Henson in this week's FidoNews
probably set us back ten years.  Now data encryption's indelibly
linked with saboteurs, criminals and terrorists. :-( 

Well, maybe not _everyone_ reads FidoNews... :-)

     Cheers,
        Rich

--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Mon, 2 Nov 92 03:48:32 PPE
To: cypherpunks@toad.com
Subject: Privacy etc.
Message-ID: <199211021047.AA04396@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



Definitely agreed with Tom's take on calling it "privacy" instead of
"encryption."  Connotations are entirely positive, tie in with modesty and
domestic comfort and other nice things.  

Privacy and it's opposite: The following quote comes from the novel _We_ by
Eugene Zamiatin, who wrote it in the USSR in the 20s only to see it banned
and himself exiled to Paris.  _We_ was also a primary source of inspiration
for Orwell's _1984_, and is definitely worth reading.

"Normally we live surrounded by transparent walls which seem to be knitted
of sparkling air; we live beneath the eyes of everyone, always bathed in
light.  We have nothing to conceal from one another; besides, this mode of
living makes the difficult and exalted task of the Guardians much easier.
Without it many bad things might happen."

Transparent walls with nothing to conceal.  And of course, people who live
in glass skyscrapers don't throw stones...

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: SIVAI%FRSAC11.BITNET@pucc.Princeton.EDU
Date: Mon, 2 Nov 92 04:40:39 PPE
To: cypherpunks@toad.com
Subject: request
Message-ID: <9211021140.AA19067@toad.com>
MIME-Version: 1.0
Content-Type: text/plain



Hello ,

I wish i knew the internet address , if any
, to which one should ask so to subscribe
to the 'sci.cryp' usenet's bb . I'd like
to know either what cypherpunk stands for ?
I'm interested in mathematical processing
of datum ( well datas or datum....a key issue
no doubt ) . Anyway i thank you in advance .
Regards    Louis Safer





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 3 Nov 92 11:16:54 PPE
To: cypherpunks@toad.com
Subject: Update on Crypto Session at Hackers
Message-ID: <9211031813.AA14130@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Here's the semi-final information on the Crypto Session at Hackers
this coming weekend:

(Note: These inputs and volunteered talks came in over the past
several days. There may be some changes of course. I'd like to see us
get together---anybody who is reading this message---on FRIDAY NIGHT,
in the refreshment room at MIDNIGHT, so we can plan, make any schedule
changes, etc. This is of course up to you folks. I'll post a message
somewhere prominent reminding you and listing time and location, if
different from above.)

* Time: Saturday afternoon, probably 3:00--4:30 (check the schedule!)
        (in an earlier update I mistakenly said we had only an hour)

* Format: 7-10 minute talks by 4-5 people, followed by open
discussion, questions, debate, etc.

* Schedule: 

- Opening comments, groundrules, settling down, etc. (5-10 min), Tim
May  (I'll point people to a glossary posted on the wall and ask them
not to interrupt the speakers with questions about the basics of
crypto, such as whether DES has a trapdoor, etc.)

- PGP, Fidonet, and Mail....Tom Jennings

- Diffie-Hellman key exchange for rlogin, etc....John Gilmore

- Anonymous remailers and DC-Nets....Eric Hughes

- Digital time-stamping....either Stu Haber or W. Scott Stornetta

- Open discussion, debate, etc. (45 minutes)

I'll be the moderator, to keep folks to their time allotment.

* If you have "poster" material, please bring it

* We can also suggest that the discussion be continued later that
evening, in one of the ad hoc sessions around midnight. Maybe some new
topics can be be planned for a late night session.

* Eric Hughes has suggested we stamp our badges with my red "CRYPTO"
stamp, so that we can know ourselves (sort of a crypto oxymoron, eh?).
See me and I'll stamp you, if you wish.

Thanks for all of your excellent suggestions. I think this could be
one of the best sessions at Hackers.

--Tim May,  408-688-5409

 
-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: norm@xanadu.com (Norm Hardy)
Date: Tue, 3 Nov 92 12:37:42 PPE
To: cypherpunks@toad.com
Subject: another service
Message-ID: <9211031859.AA01697@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


I think that there is an even easier time stamping service than that described 
by Eric Hollander. It too requires a trusted service with a trusted clock. It 
has just two key pairs, A and B. The protocol is that you send it a message, 
perhaps with payment under public-A. It returns the message joined with the 
time provided by its clock under key private-B. The returned message provides 
evidence in the future that you held the original message at the time 
indicated in the returned message. This protocol requires no data base of 
keys.
 
It was once the practice (perhaps still) to mail oneself (US mail) a certified  
envelope with information that one might want to prove that he had had at some 
earlier date. One would then keep but not open the delivered envelope.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Paul E Baclace <peb@well.sf.ca.us>
Date: Tue, 3 Nov 92 13:16:52 PPE
To: tcmay@netcom.com
Subject: Re:  Update on Crypto Session at Hackers
Message-ID: <199211032014.AA11739@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Sounds good--too short, of course, so it is going to be challenging to 
prevent digressions. The "Crypto" stamp sounds like a good way for people
to follow up on details/questions after the session.

Paul




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Matt_Kelly <MATTKELLY@ANTIOC.ANTIOCH.EDU>
Date: Wed, 4 Nov 92 01:44:48 PPE
To: cypherpunks@toad.com
Subject: Please remove me from the list
Message-ID: <01GQQN03LOTC00041P@ANTIOC.ANTIOCH.EDU>
MIME-Version: 1.0
Content-Type: text/plain



Please remove me from the cypherpunks distribution list.  This is the second
time I've asked.		thanks, MattKelly@antioc.antioch.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: shipley@@tfs.COM
Date: Thu, 5 Nov 92 00:56:03 PPE
To: cypherpunks@toad.com
Subject: random numbers
Message-ID: <9211050754.AA03719@merde.tfs.com>
MIME-Version: 1.0
Content-Type: text/plain




Here is some code to run on a SparcStaion (I or II) to generate random
numbers based on noise from the audio chip.  I have not tested the true
randomness of the out but cause I don't know how.  Thus if anyone can
please do and send me the results.  I suppose some minor tweeking can be
made for the mid range gain for a better spread. 

unfortunatly there is no way to turn off the u-law audio compression
the chip uses to outputs data if you plot the out put you will see the
problem the compression caused.



#! /bin/sh
# here be a shar file
echo x - Audio/Makefile
cat >Audio/Makefile <<'!E!O!F!'

LD= $(CC)
CC= cc

LDFLAGS=-g
CFLAGS=-g -I/usr/demo/SOUND -I/usr/local/include

LIBS= -L/usr/demo/SOUND/ -laudio

audio_rand: audio_rand.o
	$(LD) $(LDFLAGS) audio_rand.o $(LIBS) -o $@

test: audio_rand
	audio_rand | head -10000 > \#fff
	echo "plot '#fff'" | gnuplot

!E!O!F!
#! /bin/sh
echo x - Audio/audio_rand.c
cat >Audio/audio_rand.c <<'!E!O!F!'
static char *_author = "Peter Shipley\n";

#define AUDIO_CHIP
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sun/audioio.h>
#include <sbusdev/audio_79C30.h>
#include <multimedia/ulaw2linear.h>

static char *_who_did_it = "Peter M Shipley (1992) [v0.1]\n";

/* X:  0-15 
   R:  16-31
   GX: 32-33
   GR: 33-34
*/

#define MMR2_BITS 45


#define GX_GAIN 32


main()
{
struct audio_ioctl ai;
extern void bzero();
int fd;
int j, i;

    if( (fd = open("/dev/audio", O_RDONLY)) < 0) {
	perror("open:");
	exit(1);
    }

    bzero(ai, sizeof(struct audio_ioctl) );

    ai.control = AUDIO_MAP_ALL;

    if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) {
	perror( "AUDIOGETREG ALL:" );
	exit(1);
    }
    /* set audio input to a unconnected pin (audio input B) */
    ai.data[MMR2_BITS] = ( ai.data[MMR2_BITS] & ~AUDIO_MMR2_BITS_AINB);

    /* set gain of the GX reg to the max */
    ai.data[GX_GAIN] = 0x7F;
    ai.data[GX_GAIN+1] = 0x0;

    for(i=0;;) {
	char buf[BUFSIZ];

	read(fd, buf, BUFSIZ);

	for(j=0; j<BUFSIZ ; j++)
	    printf("%d %d\n", i++, audio_u2s(buf[j]));
    }
}
!E!O!F!
#! /bin/sh
echo x - Audio/reg.c
cat >Audio/reg.c <<'!E!O!F!'
static char *_author = "Peter Shipley\n";

#define AUDIO_CHIP
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sun/audioio.h>
#include <sbusdev/audio_79C30.h>

static char * print_byte();

static struct _map {
	char *label;
	char size;
} map[] = {
    "X filter", 16,
    "R filter", 16,
    "GX Gain", 2,
    "GR Gain", 2,
    "GER Gain", 2,
    "Sidetone", 2,
    "Frequency Tone gen", 2,
    "Amplitude Tone gen", 2,
    "MMR1", 1,
    "MMR2", 1
};

#define NMAPS  (sizeof(map) / sizeof(struct _map) )

struct audio_ioctl ai;

main()
{
extern void bzero();
int fd;
int oldmmr2;
int newmmr2;

    if( (fd = open("/dev/audio", O_RDWR)) < 0) {
	perror("open:");
	exit(1);
    }

    dump(fd);

    /*
    bzero(ai, sizeof(struct audio_ioctl) );
    ai.control = AUDIO_MAP_GX;
    if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) {
	perror( "AUDIOGETREG MMR2:" );
	exit(1);
    }

    ai.data[0] = ai.data[1] = 0;
    if ( ioctl( fd, AUDIOSETREG, &ai ) < 0 ) {
	perror( "AUDIOSETREG MMR2:" );
	exit(1);
    }

    */

    sleep(5);
    dump(fd);

}


dump(f)
int f;
{
int i,k;

    bzero(ai, sizeof(struct audio_ioctl) );
    ai.control = AUDIO_MAP_ALL;
    if ( ioctl( f, AUDIOGETREG, &ai ) < 0 ) {
	perror( "AUDIOGETREG MMR2:" );
	exit(1);
    }


    k=0;
    for(i = 0 ; i < NMAPS ; i++) {
	int j;
	(void) printf("%s:\n", map[i].label);
	for(j=1; j <= map[i].size; j++,k++) {
	    (void) printf("%10s", print_byte(ai.data[k]));
	    if ( (j % 7) == 0)
		(void) fputc('\n', stdout);
	}
	(void) fputc('\n', stdout);
    }

    (void) fputc('\n', stdout);
}




static char *
print_byte(c)
char c;
{
static char bt[9];

    bt[0] = ( (c & 0x01) ? '1' : '0');
    bt[1] = ( (c & 0x02) ? '1' : '0');
    bt[2] = ( (c & 0x03) ? '1' : '0');
    bt[3] = ( (c & 0x04) ? '1' : '0');
    bt[4] = ( (c & 0x05) ? '1' : '0');
    bt[5] = ( (c & 0x06) ? '1' : '0');
    bt[6] = ( (c & 0x07) ? '1' : '0');
    bt[7] = ( (c & 0x08) ? '1' : '0');
    bt[8] = NULL;

    return bt;
}
!E!O!F!




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: efrem@informix.com (Efrem Lipkin)
Date: Thu, 5 Nov 92 04:30:16 PPE
To: cypherpunks@toad.com
Subject: a cryptographic deal with the devil
Message-ID: <9211051116.AA27015@godzilla.informix.com>
MIME-Version: 1.0
Content-Type: text/plain


It is widely believed that the Police, the FBI, and other government
agencies tap many more phones than they admit in public. This is 
not counting the NSA's monitoring of all the international traffic
they can stuff into a computer.

Now the FBI wants telephone switch manufactures to supply them
with desktop phone tapping technology. Real-time delivery of all
conversations straight to the agent's desk. This is scary, but it might
an opportunity. 

Given that congress is likely to eventually allow the FBI this tech toy,
would you go along with a deal that all taps  would really require a
court order and that the exact time and location of all taps would
eventually be made public? No cheating possible.

I believe such an compromise may be possible via cyptographic
technology, I've not worked out the details, but here is a sketch
of the idea. 

The legislation authorizing the tapping facilities would require that each tap
be activated by a key supplied by a court. Each tap
would require a new key. The switching gear would not only
enforce the key mechanism, but transmit a record of the tap to some 
agency outside  the court system. Both the courts and this 
agency would be required to periodically make public all old taps. 
Part of this information would include tamper-proof sequence codes and
signatures to guarantee that all taps were in fact reported.

The law would effectively be enforced by the switch hardware. We
would not only know how many phones were tapped, but whose 
phones were tapped. This last would pose a privacy problem, The law could just
require tappees being eventually informed of the
invasion of their lives, rather than public disclosure.

Problems: 

* We consent to the process, it legitimates phone taps.

* The hardware would be in place for massive monitoring of
communications if the government could get the public to
accept dropping the limitations of the scheme. [It might
be possible to limit the abuse by having the switches
communicate and not accept anymore than a 1,000 taps a
year.]

* The lobbying for this would be difficult.

Additional opportunity:

* By proposing and lobbying for this type of scheme, it could
be made obvious that the cops and mega cops want to maintain
much closer surveillance than they are willing to admit. However,
you'd have to be prepared for them to accept the compromise. They
may figure on making all their illegal taps via other means.

--efrem




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Thu, 5 Nov 92 18:25:03 PPE
To: cypherpunks@toad.com
Subject: random numbers (resend)
Message-ID: <9211060124.AA11182@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



[my first send bounced so I am resending]

Here is some code to run on a SparcStaion (I or II) to generate random
numbers based on noise from the audio chip.  I have not tested the true
randomness of the out but cause I don't know how.  Thus if anyone can
please do and send me the results.  I suppose some minor tweeking can be
made for the mid range gain for a better spread. 

unfortunatly there is no way to turn off the u-law audio compression
the chip uses to outputs data if you plot the out put you will see the
problem the compression caused.



#! /bin/sh
# here be a shar file
echo x - Audio/Makefile
cat >Audio/Makefile <<'!E!O!F!'

LD= $(CC)
CC= cc

LDFLAGS=-g
CFLAGS=-g -I/usr/demo/SOUND -I/usr/local/include

LIBS= -L/usr/demo/SOUND/ -laudio

audio_rand: audio_rand.o
	$(LD) $(LDFLAGS) audio_rand.o $(LIBS) -o $@

test: audio_rand
	audio_rand | head -10000 > \#fff
	echo "plot '#fff'" | gnuplot

!E!O!F!
#! /bin/sh
echo x - Audio/audio_rand.c
cat >Audio/audio_rand.c <<'!E!O!F!'
static char *_author = "Peter Shipley\n";

#define AUDIO_CHIP
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sun/audioio.h>
#include <sbusdev/audio_79C30.h>
#include <multimedia/ulaw2linear.h>

static char *_who_did_it = "Peter M Shipley (1992) [v0.1]\n";

/* X:  0-15 
   R:  16-31
   GX: 32-33
   GR: 33-34
*/

#define MMR2_BITS 45


#define GX_GAIN 32


main()
{
struct audio_ioctl ai;
extern void bzero();
int fd;
int j, i;

    if( (fd = open("/dev/audio", O_RDONLY)) < 0) {
	perror("open:");
	exit(1);
    }

    bzero(ai, sizeof(struct audio_ioctl) );

    ai.control = AUDIO_MAP_ALL;

    if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) {
	perror( "AUDIOGETREG ALL:" );
	exit(1);
    }
    /* set audio input to a unconnected pin (audio input B) */
    ai.data[MMR2_BITS] = ( ai.data[MMR2_BITS] & ~AUDIO_MMR2_BITS_AINB);

    /* set gain of the GX reg to the max */
    ai.data[GX_GAIN] = 0x7F;
    ai.data[GX_GAIN+1] = 0x0;

    for(i=0;;) {
	char buf[BUFSIZ];

	read(fd, buf, BUFSIZ);

	for(j=0; j<BUFSIZ ; j++)
	    printf("%d %d\n", i++, audio_u2s(buf[j]));
    }
}
!E!O!F!
#! /bin/sh
echo x - Audio/reg.c
cat >Audio/reg.c <<'!E!O!F!'
static char *_author = "Peter Shipley\n";

#define AUDIO_CHIP
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sun/audioio.h>
#include <sbusdev/audio_79C30.h>

static char * print_byte();

static struct _map {
	char *label;
	char size;
} map[] = {
    "X filter", 16,
    "R filter", 16,
    "GX Gain", 2,
    "GR Gain", 2,
    "GER Gain", 2,
    "Sidetone", 2,
    "Frequency Tone gen", 2,
    "Amplitude Tone gen", 2,
    "MMR1", 1,
    "MMR2", 1
};

#define NMAPS  (sizeof(map) / sizeof(struct _map) )

struct audio_ioctl ai;

main()
{
extern void bzero();
int fd;
int oldmmr2;
int newmmr2;

    if( (fd = open("/dev/audio", O_RDWR)) < 0) {
	perror("open:");
	exit(1);
    }

    dump(fd);

    /*
    bzero(ai, sizeof(struct audio_ioctl) );
    ai.control = AUDIO_MAP_GX;
    if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) {
	perror( "AUDIOGETREG MMR2:" );
	exit(1);
    }

    ai.data[0] = ai.data[1] = 0;
    if ( ioctl( fd, AUDIOSETREG, &ai ) < 0 ) {
	perror( "AUDIOSETREG MMR2:" );
	exit(1);
    }

    */

    sleep(5);
    dump(fd);

}


dump(f)
int f;
{
int i,k;

    bzero(ai, sizeof(struct audio_ioctl) );
    ai.control = AUDIO_MAP_ALL;
    if ( ioctl( f, AUDIOGETREG, &ai ) < 0 ) {
	perror( "AUDIOGETREG MMR2:" );
	exit(1);
    }


    k=0;
    for(i = 0 ; i < NMAPS ; i++) {
	int j;
	(void) printf("%s:\n", map[i].label);
	for(j=1; j <= map[i].size; j++,k++) {
	    (void) printf("%10s", print_byte(ai.data[k]));
	    if ( (j % 7) == 0)
		(void) fputc('\n', stdout);
	}
	(void) fputc('\n', stdout);
    }

    (void) fputc('\n', stdout);
}




static char *
print_byte(c)
char c;
{
static char bt[9];

    bt[0] = ( (c & 0x01) ? '1' : '0');
    bt[1] = ( (c & 0x02) ? '1' : '0');
    bt[2] = ( (c & 0x03) ? '1' : '0');
    bt[3] = ( (c & 0x04) ? '1' : '0');
    bt[4] = ( (c & 0x05) ? '1' : '0');
    bt[5] = ( (c & 0x06) ? '1' : '0');
    bt[6] = ( (c & 0x07) ? '1' : '0');
    bt[7] = ( (c & 0x08) ? '1' : '0');
    bt[8] = NULL;

    return bt;
}
!E!O!F!




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 6 Nov 92 04:16:03 PPE
To: efrem@informix.com
Subject: Re:  a cryptographic deal with the devil
Message-ID: <199211061115.AA02435@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Re. the digital wiretapping "compromise."  As a telecom professional I
absolutely resent and will resist any attempts to mandate backdoors into my
PBXs.  No compromise on that.  Period.  We've all heard the arguements many
times: vast surveillance power, diminution of privacy, potential major
security problems...  

I'd like to suggest something of a compromise which doesn't have these
risks.  Common carriers (local and long distance telcos) are currently
required to provide access to line terminals when presented with a court
order for a wiretap.  This access could reasonably be extended to requiring
the telco to connect a demultiplexer in the case of digital transmission, or
some kind of appropriate signal splitter in the case of fiber optics.  The
agency requesting the tap would of course pay the bill for materials and
labor.  Now this gets law enforcement their demultiplexed signal path so
they can tap only the intended target line, but it preserves the existing
structure which prevents law enforcement "hacking," since no backdoors would
be involved. 

For PBXs (this is my department), a slightly distasteful but acceptable
compromise would be to have interconnect companies (the folks who install
your PBX or key system) register with the local operating telcos, providing
the interconnect company's name and contact information on the telco record
for each subscriber.  So for instance, General Widgets has XYZ Telecom
install a new PBX; XYZ Telecom is required to inform the local operating
company that they have just acquired General Widgets as a client. Now if a
law enforcement agency gets a court order for a tap, they go to the local
telco and ask who the interconnect company is for that subscriber.  (We're
talking here about a scenario in which one or a small number of extensions
in a phone system are believed to be used for criminal purposes, so law
enforcement has to tap those extensions only and not everyone who is on that
phone system.)  Now law enforcement visits the interconnect company and
presents them with the court order, which requires the interconnect company
to provide access to the line terminals of the suspect extension(s), and/or
provide a demultiplexer etc. if needed (at law enforcement's expense of
course)... and of course, under penalty of contempt of court, refrain from
disclosing the situation to the client.  

Now this gets law enforcement their legitimately needed access to suspect
extensions on PBXs, prevents interconnect companies from blowing the whistle
to their clients, and still preserves privacy protections since there is no
backdoor into the system.  

Now here is why I think the FBI wants backdoors:  Recall that under the "war
on drugs" etc., a ruling was handed down (I can't recall which branch of
govt originated this) which says that a wiretap may be conducted for up to
72 hours for "investigational purposes" without a court order; and the
material recorded may then be used to go and get a court order for a
continuing wiretap.  This places authority in the hands of law enforcement
agencies to conduct taps any time they suspect someone of something, and
then go see the judge after the fact.  Now without backdoors, law
enforcement has to depend on the goodwill of telcos to get access, and is
kind of stuck when it comes to PBXs and key systems.  I'm willing to bet
there is a pretty substantial amount of "investigational" tapping going on,
and that the FBI is interested in vastly expanding it.  The compromises I'm
proposing don't address this investigational tapping, and that's just fine,
since that ought to be challenged in court or defeated one way or another.

-gg@well




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Fri, 6 Nov 92 05:03:26 PPE
To: cypherpunks@toad.com, gnu
Subject: 1993 RSA Data Security Conference
Message-ID: <9211061203.AA20359@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


RSA is putting on a conference on public key cryptography on the SF
peninsula on January 14th (conference) and 15th (tutorials and
exposition).  Last year's conference was smaller (one day) and quite
interesting.  Many of the best cryptographers in the world attended.
It's worth prying yourself out of your usual haunts for.

The conference is free.  Registration is "extremely limited, and is
first come, first served".  Phone +1 415 595 8782 and ask for
Conference Registration, to reserve your place (and a place for anyone
else at your company who's interested).  I'll see you there!

	John Gilmore





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mcmahonm@wybbs.mi.org (Mike McMahon)
Date: Sat, 7 Nov 92 19:08:31 PPE
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9211072044.AA14863@wybbs.mi.org>
MIME-Version: 1.0
Content-Type: text/plain


Please add my address to the mailing list.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Mon, 9 Nov 92 13:39:59 PST
To: cypherpunks@toad.com
Subject: Analysis of cost to produce random serail generator.
Message-ID: <9211092136.AA25999@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


At Hackers 8.0,  we had a discussion about the feasability of someone
building a random data generator.    I volunteered to look into this
with the hopes of making a cheap and inexpensive device that has
2 DB-9 connectors (Serial through box) to be used to generate random
serial data at a particular baud rate.

Today,  I called Newbridge Micro,  they faxed me the data sheets,  and
gave me the number for a local rep in San Jose.   (408) 258-3600,
but I was appalled at the price.    They wanted $52.50 each in
100 quantity.   So it is clear that if I use this chip,  which really
is a hybred,   I cannot charge $50 each.    So we have to decide
what to do,   or how much more it will cost.

After examining the data sheet,  the chip is probed by a pulse,  and
a bit comes out with an equal probability of a "1" or a "0".   Sorta
like a coin toss.  

I think that the perifery cost of the other electronics,   such as
shift registers,  or UART which would be necessary to clock the bits
into an 8 bit register,  etc,  would cost about $6 - $8 in cost,  then
I will have to fab the boards.   I have friend at Douglas Electronics
who can give me a good price.   It would cost $150 setup charge for the
PC boards and $2 per board. 

1 ea  RBG1210           $52.50
1 ea  PC board		 $2.00
various chips		 $8.00
Setup 			 $1.50   (1/100th setup charge)

Total parts		$63.50  (100 quantity) 

Cost (4 X parts)       $254.00   

So,  it is clear that the cost is rather high,   and not everyone can
afford this.     But if you think that people will want to buy it at
that price,    I can go ahead and do it,    but the cost to me would
be about $250 to build just one of them,  and I have someone who can
loan me the money to make a prototype.   This also includes design
time and use of an electronics lab to test and get it running.

I wouldn't be able to borrow $6350 to build 100 of them,  and I think
I can talk the rep into letting me purchase them in smaller quantity,
so I can build them on demand.    I'm just not so sure that people will
want to pay $254 for one of these.    So please lets discuss this,  
among our group to determine if this price is reasonable.

Although,   it IS possible to use a cesium noise source (Don't know
the cost of that)  and perhaps I can cut that price down by about
a half or a third,  but the design time would be much increased,
and perhaps there would be twice as much electronics,  and perhaps
the posibility that the randomness won't be as good.

John D.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pozar@kumr.lns.com (Tim Pozar)
Date: Mon, 9 Nov 92 15:09:09 PST
To: crunch@netcom.com (John Draper)
Subject: Re: Analysis of cost to produce random serail generator.
In-Reply-To: <9211092136.AA25999@netcom2.netcom.com>
Message-ID: <m0moiDw-0000egC@kumr.lns.com>
MIME-Version: 1.0
Content-Type: text/plain


John Draper wrote:
> [...]
> So,  it is clear that the cost is rather high,
> [...]
> Although,   it IS possible to use a cesium noise source
> [...]
> John D.

  Geez... What happened to the idea of using a reversed-biased diode?
That into a cheapy A/D and into a UART, should do the trick...

                     Tim
-- 
Internet: pozar@kumr.lns.com               FidoNet:  Tim Pozar @ 1:125/555
UUCP:     ...!uunet!kumr.lns.com!pozar
Snail:    Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
Voice:    +1 415 788 2022




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 9 Nov 92 15:09:26 PST
To: crunch@netcom.com
Subject: Analysis of cost to produce random serail generator.
In-Reply-To: <9211092136.AA25999@netcom2.netcom.com>
Message-ID: <9211092238.AA05660@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: crunch@netcom.com (John Draper)

>Although,   it IS possible to use a cesium noise source (Don't know
>the cost of that)  and perhaps I can cut that price down by about
>a half or a third,  but the design time would be much increased,
>and perhaps there would be twice as much electronics,  and perhaps
>the posibility that the randomness won't be as good.

Remember also that a radioactive source thats decaying fast enough to
put out 20,000 bits a second the way the RBG1210 can isn't something
you want to stand near.

>Total parts		$63.50  (100 quantity) 
>
>Cost (4 X parts)       $254.00   

I don't get this -- why is cost four times parts? Is that including
profit?

Also, shouldn't it just be possible to buy a couple of components and
do as well as the Newbridge Micro unit? It would seem that we should
be able to build something a lot cheaper than $52 if all we need is a
noise source that will make a line go high or low on a clock input...

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: efrem@spitha.informix.com (Efrem Lipkin)
Date: Mon, 9 Nov 92 21:57:15 PST
To: cypherpunks@toad.com
Subject: Re:  a cryptographic deal with the devil
Message-ID: <9211100543.AA00737@spitha.informix.com>
MIME-Version: 1.0
Content-Type: text/plain


>Re. the digital wiretapping "compromise."  As a telecom professional I
>absolutely resent and will resist any attempts to mandate backdoors into my
>PBXs.  No compromise on that.  Period.  We've all heard the arguements many
>times: vast surveillance power, diminution of privacy, potential major
>security problems...  

I think you missed the point of my proposal. It is to create a situation
in which all taps must be court ordered and eventually disclosed. 
The police have no business making "investigational" taps, they are
not entrepreneurs in search of new business opportunities.

My prefered solution is no taps. In my experience taps are more common
for political reasons than police reasons. I think anyone who believes
anything the FBI says without proof must have not been reading the paper
for the last several decades.

If the political process will not ban wire (fiber) tapping then it seems 
sensible to try and force all easedropping into the public record.

I see no reason to care where the police put their equipment so long as 
there is no way they can create taps without going to court and creating 
a public record. I do not see the difference between building the tap
in or making it an extra cost option, unless it can be made a very expensive
option. If tap control cannot be reliably accomplished via technology, 
cryptographic or otherwise, then we might as well just fight against 
all tapping and for universal encryption even if it is a lost cause.

I think it is clear that no organization and especially no government or
corporation can be trusted to police itself either at the frontdoor or
the backdoor.

--efrem




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 11 Nov 92 00:58:51 PST
To: cypherpunks@toad.com
Subject: Hackers Conference Report
Message-ID: <9211110855.AA18408@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Fellow Cypherpunks,

Here's a trip report I just sent to another mailing list I'm active
on, the "Extropians" list. That's why I "introduce" Tom Jennings, John
Gilmore, and Eric Hughes...clearly they need no introduction to
readers of _this_ list (although a lot of new folks have signed up
recently, I hear).

By the way, I just picked up the latest "Mondo 2000." Our own Jude
Milhon's article, "The Cypherpunk Movement," is on pp. 36-37 (Issue
#8). The address "cypherpunks@toad.com" is mentioned, so we may get
even more new folks. Also some good stuff on MindVOX, phreaking, etc.

--Tim


HACKERS CONFERENCE REPORT

I just returned from Hackers 8.0, held 6-8 November in Lake Tahoe,
California. Approximately 170 attendees this year.

Some Highlights:

* Our crypto session went extremely well. The talks were on PGP and
FidoNet, Diffie-Hellman key exchange for rlogin, digital
time-stamping, and anonymous remailers. More comments later.

* Mike Godwin of the Electronic Frontier Foundation (EFF) spoke on the
developing conflict between personal privacy and law enforcement,
including comments on the "key registration" trial balloon I posted
about earlier. (Godwin told me he believes the Denning proposal is
deadly serious, that the Department of Justice has put a high priority
on limiting the use of cryptography.)

* Hacking was well represented. Besides our crypto panel, sessions on
cellular phone phreaking and illegal mods to telecom equipment drew
large crowds (a "how to" talk on reprogramming the 8051 micro in the
Oki 900 cellphone was especially useful).

* Eric Drexler gave a talk on nanotechnology (surprise!), with an
emphasis on needed work in the next couple of years. Drexler argued
that proto-assemblers could be built in as short as 16 years, though
there was some skepticism expressed. He also presented a calculation
that the "cost" of delaying nanotech is $25 billion a _day_. (I
suggested we all skip dinner that night and instead put in another
hour in the labs!)

* Marvin Minsky answered questions, saying he rarely prepares in
advance. AI, robotics, gene expression in embryos, and software were
all covered.

* Allan Huang of AT&T gave an energetic 90 minute talk on optical
computing, going from optical deconvolvers to "computer origami" to
optical switches to Sagnac fibers that can store light pulses 6
femtoseconds long! Definitely the most stimulating talk.

* Demos in the machine room were better than ever. The "Reality
Engine" from Silicon Graphics displayed photorealistic simulations.
Lots of Suns, NeXTs, and Macs. Films of SIGGRAPH papers, chaos and
fractals, and artificial life were shown at night. Rudy Rucker's
session on cellular automata went well.



MORE ON CRYPTO

Since cryptology and the activities of the "cypherpunks" mailing list
are of central concern to me, I'll concentrate on those topics.

Our panel was in "prime time," mid-Saturday afternoon, with about 100
in attendance, including a couple of journalists (notably John Markoff
of the "New York Times"...if anybody sees an article on this by him,
please send me a note about it, OK?). The audience had been prepped
for crypto by the comments Friday night by Mike Godwin of the EFF and
by a 3 hour rump session on "Digital Cash" from 1 a.m. to 4 a.m on
Saturday (remember "hacker hours").

Tom Jennings, one of the chief forces behind FidoNet, an "anarchic"
net made up of PCs talking to other PCs, spoke on efforts to spread
PGP (Pretty Good Privacy) to as many FidoNet users as possible. It
looks like its happening and this will be another avenue to ensure
that the "crypto genie" gets safely out of the bottle.

John Gilmore, an early UNIX/Sun pioneer and current principal at
Cygnus Support, amongst other things, spoke on increasing security
against Internet eavesdroppers by using the Diffie-Hellman key
exchange protocol for rlogin (for example). This is something we can
do fairly soon.

Stu Haber and Scott Stornetta of Bellcore (formerly part of Bell Labs)
reported on their digital time-stamping system. Some document to be
"notarized" is hashed to produce a fairly short number which is hard
to forge (i.e., it is very hard to find another document which hashes
to the same value). This hash value is then published in, say, a
widely read newspaper. If a dispute arises about the time a document
was written, the published has value is persuasive. Bellcore actually
operates such a service (check the legal notices in the Sunday "New
York Times").

Eric Hughes, a mathematician who worked briefly for David Chaum's
"DigiCash" outfit, described anonymous remailers implemented in Perl
and now running. He also mentioned Hal Finney's version which embeds
PGP in the remailer, allowing more security. This generated a lot of
excitement, as the ideas of "crypto anarchy" became apparent to all.

(John Little, owner and operator of the "Portal Communications
Company," a Bay Area-based Internet access service, got excited and
offered to run the remailers on his system! The genie is further out
of the bottle. Now if we can only get GEnie to do the same!)

The spirit of contributing to the larger cause of using crypto to
_directly_ protect privacy was exhilarating. More people spoke of
actual code they plan to write (as with Russell Whittaker's offer a
few weeks ago to help with ProComm mods). 

There was a real sense that Things Had Changed. With PGP 2.0 arriving
a few months ago (and still spreading), with the onset of the
"Cypherpunks" group (which got a somehat cryptic write-up by Jude
Milhon in the just-published Issue #8 of "Mondo 2000"...but since she
coined the term "cypherpunks" to describe us, her article can afford
to be cryptic, no?), and with the "Hacker Crackdown" all around us
(Sun Devil, Legion of Doom, S.266 attempt to ban encryption, FBI's
"Digital Telephony Bill," and the latest "trial balloon" to register
keys), the time is right.

In the next several months I expect the media, via more articles in
magazines like "Mondo 2000" and by articles on crypto policy, to focus
in on this issue. Even the "Village Voice" is interested in crypto issues
(theme: crypto privacy vs. Big Brother).

These are exciting times. If I'm ever busted for sedition, money
laundering conspiracy, violation of the Munitions Act, RICO Act
violations, or just plain old political incorrectness, carry on the
fight. The stakes are high.


--Tim

--
..........................................................................
Timothy C. May | Crypto Anarchy: encryption, digital money,
tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
408-688-5409 | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 11 Nov 92 08:24:36 PST
To: crunch@netcom.com
Subject: Random number generators
Message-ID: <9211111624.AA08843@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



There seems to be some confusion over this random number device.

Perry Metzger forwarded me some information about Newbridge
Microsystems and the part number of a chip that made random numbers.
At the crypto BOF at hackers I mentioned that there was a need for a
hardware random number generator and that I knew of some chip to do
it.  John Draper, who was there, expressed a desire to work on such a
device.  I forwarded him the information about the chip.

What I didn't know was the cost or design of this chip.  It appears to
use a radioactive source to make random numbers.  This may account for
the cost.  In any case, it is likely that most applications don't need
this kind of chip.

What is needed, though, is _some_ kind of chip.  John Draper is eager
to manufacture such a device, once we have a design.  Would those
people willing to help on this design please get in touch with him
directly and start a conversation about it.  The conversation could
reasonably be discussed on the list, if enough are interested.

FYI, random numbers are used generally to create single-use session
keys in a wide variety of crypto protocols, including Diffie-Hellman
key exchange.  Hardware random number sources will be a standard
component of all computers in the near future.

As far as the design of the device itself goes, the numbers that come
out of it don't have to be fully random.  Non-randomness can be
corrected in software.  Two characteristics of the output, though will
help such correction.  First, the number of ones and zeros should be
the same.  Not only is this useful for correction, but it is easy to
do in hardware.  Second, effort should be made to make sure that the
generator does not pick up cyclic noise from its environment.  This
means attention to coupling, shielding, and packaging.  No extra
expense, likely, but definitely to be thought about some.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 11 Nov 92 08:33:18 PST
To: cypherpunks@toad.com
Subject: Mac PGP version
Message-ID: <9211111630.AA09056@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I found the address for the Mac version of PGP.

anon-ftp to mac.archive.umich.edu
directory /mac/util/encryption

Would someone try this out and report back to the list how it works?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: estensla@mipos2.intel.com (Erik Stensland)
Date: Wed, 11 Nov 92 09:12:11 PST
To: cypherpunks@toad.com
Subject: Remove my name please
Message-ID: <9211111710.AA08221@mipos2>
MIME-Version: 1.0
Content-Type: text/plain



Please have my name removed from the mailing list!
Thanks




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 11 Nov 92 09:25:31 PST
To: cypherpunks@toad.com
Subject: Re: Random number generators
In-Reply-To: <9211111657.AA13574@newsu.shearson.com>
Message-ID: <9211111722.AA06575@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Eric Hughes comments and then Perry Metzger responds:

> >Perry Metzger forwarded me some information about Newbridge
> >Microsystems and the part number of a chip that made random numbers.
> >At the crypto BOF at hackers I mentioned that there was a need for a
> >hardware random number generator and that I knew of some chip to do
> >it.  John Draper, who was there, expressed a desire to work on such a
> >device.  I forwarded him the information about the chip.
> 
> >What I didn't know was the cost or design of this chip.  It appears to
> >use a radioactive source to make random numbers.  This may account for
> >the cost.  In any case, it is likely that most applications don't need
> >this kind of chip.
> 
> Just for the record...
> As the data sheet makes clear, it most certainly DOES NOT use a
> radioactive source. Its very hard to get 20kbits/sec of random numbers
> reliably out of any radioactive source you are going to want to be
> near, anyway. It operates off of thermal noise just like virtually
> every other such device.
> 
> It should be possible to build a similar device out of ordinary
> discrete components without overwhelming difficulty. The only problem
> would be to make sure that the output was reliably random, and not
> overly dependant on things like temperature.
> 
> Perry

Perry is correct. Getting 10K or more bits per second from a
radioactive soure usually means it is close enough/strong enough to
"drift" the device to the point of radiation-induced permanent failure
in a matter of weeks or months (if not much sooner, but this is all so
dependent on exact calculations and lab experiments).

Tony Patti, editor of a small crypto journal and frequent commentator
on sci.crypt, is one of several folks who've designed thermal
noise-based RNGs. He's selling them, as I recall. I would _strongly_
advise anyone who's contemplating building and selling such a gizmo to
first see what the market has produced and whether or not it's
selling, etc.

A minor note: the bias between 0s and 1s (unequal distribution, for
example) is easily handled by considering pairs of numbers, with a "0
1" being called a "0" and a "1 0" being called a "1." 

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 11 Nov 92 11:14:11 PST
To: cypherpunks@toad.com
Subject: (fwd) A Silver Bullet to Limit Crypto?
Message-ID: <9211111910.AA19576@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Cypherpunks of the World,

Here's a new analysis of the key registration proposal I just posted
to a couple of groups.

-Tim


Newsgroups: sci.crypt,alt.privacy,comp.org.eff.talk
From: tcmay@netcom.com (Timothy C. May)
Subject: A Silver Bullet to Limit Crypto?
Date: Wed, 11 Nov 1992 18:36:44 GMT


Key Registration as a "Silver Bullet" to Limit Crypto Use


Two weeks ago, and more than 500 related messages ago, I posted the
"Trial Balloon to Ban Encryption?" message, alerting sci.crypt and
other newsgroups to the Dorothy Denning "trial balloon." Prof. Denning
has continued the balloon metaphor, calling her first proposal a "lead
balloon" and her improved, law-enforcement-friendly version a "copper
balloon." Others have called it a "uranium balloon," i.e., it's worse
than the lead balloon.

In reading the hundreds of comments about ways to bypass the Denning
proposal, about the many clever schemes to avoid detection, I came to
some realizations about the likely reason for key registration. Also,
at the recent Hackers Conference in Lake Tahoe, lots of interesting
points came up (crypto, PGP, anonymous remailers, digital cash,
privacy, and the "Crypto Crackdown," to borrow Bruce Sterling's title
of "The Hacker Crackdown," were hot topics). Mike Godwin of the EFF,
who may be reading this in comp.org.eff.talk, spoke on such
policies...he told us this kind of crackdown on crypto tools is a
priority of several government agencies and that the issue will not go
away with the new administration.

But why scheme to register keys, by whatever means, if the system is
so easily thwarted and bypassed? Neither Prof. Denning nor her
colleagues, both in and out of the NSA and FBI, are dummies.

The "silver balloon," or silver bullet, is this:

* a formal key registration system will directly affect and limit use
of the _most important_ part of public key systems: the ability to use
public key directories (like phone books) rather than set up all
communications on a one-to-one basis (as private key systems require,
for key exchange, and as many of the key registration bypasses
implicitly or explicitly require).

* enforcement, at least for publicly announced P-K keys, can be by
insisting that a special message ("This is J. Random User.") be signed
with one's registered/deposited key and then verified with the public
key to ensure the same private key-public key pair is used. (Yes,
there are still bypasses and clevernesses to spoof these systems, but
most "publicly visible" use of P-K methods, the main raison d'etre for
public keys, will be affected and effectively controlled.) Keys can
and will be registered under this proposal, but many people will
simply not bother with the hassle and just won't use P-K methods (thus
making the monitoring job easier).

* bypassing the key registration laws by "going underground" is always
possible, but for this purpose one can already use one-time pads, pack
message bits into the least significant bits of digital recordings and
images, and generally do all sorts of other devious things. The key
point is that the wide use of public key methods is reduced, which may
be the real motivation.

* reducing the wide use of crypto technology by the masses allows the
monitoring agencies a slightly easier job in monitoring those who
_are_ using crypto. One can imagine exactly the same arguments for
restricting or registering voice scramblers for phone use: by
requiring registration, fees, etc., many users will simply not bother
to use scrambling (and there may be related to spread the idea that
anyone using scrambling--or crypto in general--is somehow suspect,
must have something to hide, etc.

* the key registration ideas discussed so far severely limit use of
crypto protocols that _dynamically_ generate lots of public keys.
Cryptographic voting, most forms of digital cash, anonymous remailers,
and several other exciting uses all tend to generate a lot of keys "on
the fly." Are all of these to be registered? How? For how much money
per registration? And how long will it take? Weeks?

Instead of concentrating on how these kinds of uses, mentioned by many
people, effectively make the Denning/Rivest/Micali proposals
unworkable, we should look instead at how these proposals may _in
fact_ be aimed at limiting the explosive use of crypto for these new
applications. A government afraid of digital cash, of anonymous
remailing networks, of information markets in technologies, and of
lots of other interesting uses, may see key registration as a way to
contain this explosion.

Even if the private keys kept at the "trusted key authority" were
_never_ looked at by court order or otherwise, the key registration
act itself would place severe limits on the use of modern
cryptographic protocols for novel uses and for wide use by the public.

In this sense, the key registration idea may be a silver bullet, or
balloon, to head off these uses. A chilling effect (the "liquid
nitrogen balloon"?).

Any thoughts on this view?



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Wed, 11 Nov 92 09:08:59 PST
To: hughes@soda.berkeley.edu
Subject: Random number generators
In-Reply-To: <9211111624.AA08843@soda.berkeley.edu>
Message-ID: <9211111657.AA13574@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Eric Hughes <hughes@soda.berkeley.edu>

>There seems to be some confusion over this random number device.

>Perry Metzger forwarded me some information about Newbridge
>Microsystems and the part number of a chip that made random numbers.
>At the crypto BOF at hackers I mentioned that there was a need for a
>hardware random number generator and that I knew of some chip to do
>it.  John Draper, who was there, expressed a desire to work on such a
>device.  I forwarded him the information about the chip.

>What I didn't know was the cost or design of this chip.  It appears to
>use a radioactive source to make random numbers.  This may account for
>the cost.  In any case, it is likely that most applications don't need
>this kind of chip.

Just for the record...
As the data sheet makes clear, it most certainly DOES NOT use a
radioactive source. Its very hard to get 20kbits/sec of random numbers
reliably out of any radioactive source you are going to want to be
near, anyway. It operates off of thermal noise just like virtually
every other such device.

It should be possible to build a similar device out of ordinary
discrete components without overwhelming difficulty. The only problem
would be to make sure that the output was reliably random, and not
overly dependant on things like temperature.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: strat@intercon.com (Bob Stratton)
Date: Wed, 11 Nov 92 09:01:48 PST
To: cypherpunks@toad.com
Subject: Mac PGP
Message-ID: <9211111701.AA00740@intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


I will try out the port that Eric Hughes just mentioned, and I also
want to make it known that I'm willing to assist in any Macintosh
efforts along these lines. (FYI - I use MPW for development). 

Bob Stratton     Engineer, InterCon Systems Corp
strat@intercon.com     +1 703 709 5525 (W)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Wed, 11 Nov 92 13:01:03 PST
To: cypherpunks@toad.com
Subject: re: (fwd) A Silver Bullet to Limit Crypto?
Message-ID: <3565.2B016F5A@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: tcmay@netcom.com (Timothy C. May)
 U> 
 U> Here's a new analysis of the key registration proposal I 
 U> just posted to a couple of groups. 
 U> 
 U> -Tim


I've been crossposting selected messages, such as this one, to
FidoNet's PUBLIC_KEY conference, just FYI...

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems  (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fen@genmagic.com (Fen Labalme)
Date: Wed, 11 Nov 92 16:20:49 PST
To: Eric Hughes <hughes@soda.berkeley.edu>
Subject: Re: Mac PGP version
Message-ID: <9211112022.AA12952@>
MIME-Version: 1.0
Content-Type: text/plain


>I found the address for the Mac version of PGP.
>
>anon-ftp to mac.archive.umich.edu
>directory /mac/util/encryption
>
>Would someone try this out and report back to the list how it works?

I pulled it down and found it to be a "nice little app" with certain
problems evident from the beginning.  The major bug is **no source code**!!
 How can I trust an app to make my keys?  Why don't I just ask the NSA for
them?

What I would have liked (and expected) was a set of diff (or changed) files
from the PGP 2.0 distribution, and perhaps an extra top-level app-maker
file to put the nice wisiwyg on top.  This would show me an example, and
let me build PGP into other apps that I might build.

The next bug is no email address for Z. Fiedorowicz, so I can't complain to
him directly.

And the third apparent bug (now I haven't used this much yet) is that the
help file offers help for the standard MPW-style command line operations,
but the app is entirely menu-driven.

I hope that ZF doesn't take this as purely negative.  I am sure that he did
a good implementation, and I thank him for doing the work and for providing
a nice gui.  But I would especially like to get the source code (preferably
as minimal changes to the standard distribution so that it is clear that
the same internals are used for each).

Thanks,
Fen

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQBNAisBeSgAAAECAKvzX/54a9kC5FPXfIN7vjep64zkqXwPzr8VXkiJXyklRTRI
kyxcuNlS7ipDveilmSDYYP3W5JJMCC1HSIeCc4kABRG0HkZlbiBMYWJhbG1lIDxm
ZW5AZ2VubWFnaWMuY29tPg==
=bZWg
-----END PGP PUBLIC KEY BLOCK-----






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eli Brandt <ebrandt@jarthur.Claremont.EDU>
Date: Wed, 11 Nov 92 13:37:40 PST
To: extropians@gnu.ai.mit.edu
Subject: a name for cryptographic currency
Message-ID: <9211112137.AA22079@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


Nothing makes it big with a dodecasyllabic name.
How about "cryp"?   (Rhymes with "scrip"?)

The idea is for science-fiction writers to ditch these
central-intelligence "credits", and start naming currency 
"1gAu L5 Consortium cryp" and the like.

   Eli   ebrandt@jarthur.claremont.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Wed, 11 Nov 92 13:56:07 PST
To: cypherpunks@toad.com
Subject: My responses regarding random generator.
Message-ID: <9211112152.AA24329@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


In response to everyones comments:

   I am overwhelmed with all this response that came though
during the times I was absent from the Nets.

   At this time,  I am evaluating other approaches to this 
problem then using the Newbridge system's inflated pricey
hybred circuit.

   It is clear that a simple reversed diode circuit may not be 
enough to produce truly random data bits unless care is taken
to prevent periodic signals from being "injected" into the circuit.

   Although I don't have access to a "clean lab",  I do have
access to Techtronix scopes,  and a general HW lab,  but not sure 
if that is adequate to completly test out the circuit to determine
that things are truly random.

   An easy test I often devise is to generate a pair of random
bytes,  and display them as X, Y pairs and plot them on the
screen as pixels.    First,  I start with a clean screen,  then
plot the dots as they come in.     As these dots are plotted
on the screen,   the dots should be evenly distributed over the
screen without "bunching" or "patterns" developing.

   I know that this is not the best way to determine true 
randomness,   but it is cheap and inexpensive to do.  

   I also agree that we should all check out and determine if
there are other random generators currently available,  and
we should compile a list of them to share with the group as
proposed by Tim May.    Although I haven't yet visited the
crypt newsgroups,  I suspect that I should post a query there
to see if any such puppie exists.

   Then,  there is the speed of generating these random numbers,
and how we will want to deal with the possibility of inadequate
speed.     I suspect that serial transmission at 9500 baud might
be easily obtained,   but going much faster withoug "drift" might 
be problematic as Tim May pointed out.

   At this point,   I would now like to get some other feedback
from the group on what Zener noise source to use,   and kick 
around some design ideas.    It would be nice to be able to exchange
schematic diagrams and pass them around.  I have a Mac,   but
not everyone in this group uses them.    So what mechasim can we
imploy to send schematics around?

   My next visit to the Nets will be this weekend,   so if anyone
wants to contact me,  they can try me at (510) 769-1268,  and
it will refer to the number where I'm staying at that time.
I still have NO permenent home (after long period of unemployment),
so getting on the Nets daily will be problematic for me.

   I usually hang out in South San Jose,  at my friends VCR Repair
lab (where this hardware equipment is located),  but have no computer
set up there until we can set up proper physical security.   That
number is (408) 377-2382.   I am usually there early in the week,
because I can make calls to find work from there on Mondays.

   As I converge into a workable design and if the lab results
are encouraging,   and acceptable to the group,   I would like to
build 2 or 3 prototypes and pass them around to volunteers for
Beta testing before making them available to the group as a whole.

   I can get PC boards made via Douglas Electronics fairly 
inexpensivly,   and plan on making them as orders come in,  and
initial setup costs would be about $350.     I already have
people set up to invest this much already.

   Perhaps it would be prudent to set up a group of other HW
designers and meet physically somewhere to hammer out a design
and make this a group effort.   Do I have any volunteers?
I think only one meeting would be necessary to determine a rough
approach to take.

John D.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Wed, 11 Nov 92 15:00:43 PST
To: cypherpunks@toad.com
Subject: PGP problems with large key rings?
Message-ID: <9211112300.AA06194@servo>
MIME-Version: 1.0
Content-Type: text/plain


I'm encountering problems when I try to form a large key ring (on the
order of 150 keys, each with several signatures). The file is large
enough (60+ Kb) but it is apparently trashed; when I run "pgp -kv" on
it I only see 4 keys.

This is under UNIX, so I don't think memory exhaustion is the problem.
I'm not sure I have the latest version of the UNIX port, so if somebody
could steer me to the right repository I'd like to try that too.

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 11 Nov 92 15:18:28 PST
To: karn@qualcomm.com
Subject: PGP problems with large key rings?
In-Reply-To: <9211112300.AA06194@servo>
Message-ID: <9211112318.AA18915@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



P.S.  The maintenance release is in the works; it may fix the error
you describe.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 11 Nov 92 18:47:46 PST
To: cypherpunks@toad.com
Subject: Mac PGP version
In-Reply-To: <9211112022.AA12952@>
Message-ID: <9211120247.AA00337@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Here's the author of the Mac port I referenced:

	Zbigniew Fiedorowicz <fiedorow@function.mps.ohio-state.edu>

This fixes the second of Fen's bugs.  Contacting Zig will fix the
first (no source).

And, Fen, you attached a PGP key.  Did you really ask the NSA to
generate one for you? :-)

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Thu, 12 Nov 92 01:25:29 PST
To: cypherpunks@toad.com
Subject: (fwd) A Silver Bullet to Limit Crypto?
In-Reply-To: <9211111910.AA19576@netcom.netcom.com>
Message-ID: <9211120841.AA17711@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


I think I agree with it completely.  It is also very well written.  Is
there a well written summary and response such as this that could be
more widely distributed electronically?

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Thu, 12 Nov 92 01:09:12 PST
To: cypherpunks@toad.com
Subject: mac pgp
Message-ID: <9211120909.AA19359@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I uploaded MacPGP to my powerbook, and used it to generate a key pair.  The
user interface is easier than the Unix user interface, so I have no problem
with that, but I do have a big problem with speed.

It expects me to type in my pass phrase at about 20 words per minute.  It
beeps me if I type it faster than that.  This makes it too annoying to be
used regularly.  It should be able to accept full-speed typing on a
powerbook 100.  I know that a 100 is not a very fast machine, but still,
this is just basic keyboard input.

My powerbook is about as secure as you can get (it's with me close to 24
hours a day and probably emits very little radiation and it's not on any
kind of net), so ideally it would be my main crypto machine, but I don't
want to type my pass phrase at 20wpm, so for now I'll stick with the IBM
RS/6000 I normally use PGP on, despite its much weaker security.

The other speed problem is key generation.  This is very slow.  Maybe I am
spoiled by the RS/6000, which is extremely fast, but I still feel like it
should be faster.

Also, it does not allow itself to be backrounded properly under system 7
during key generation.

However, I must say that I am glad that Fiedorowicz and others are working
on this port.  It's a good start.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Thu, 12 Nov 92 02:38:59 PST
To: efrem@spitha.informix.com
Subject: Re:  a cryptographic deal with the devil
Message-ID: <199211121037.AA24895@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Efrem, re your item on tapping and public records.  Okay I admit it, I did
miss the point of your proposal that any tapping be made the subject of a
public record.  And basically I agree with you on that point. Now the
problem I see is that these agencies will say, "except for taps currently in
process," or "investigations which are still open," which is how the FBI
gets around FOIA a lot of the time. And we all know that in political cases,
the investigation can stay open for a hell of a long time, like until the
targeted individuals die or something. 

Maybe the way to deal with the "open investigations" issue is to mandate
disclosure of *something* anyway, in some form, on a regular basis, and
certainly it would be nice to have the scheduled disclosures take place a
month or so before elections...!

I still do not want back doors of any kind in our network.  

Now speaking of back doors, wouldn't it be a simple matter for someone to
hack out a system which would detect the signals coming into the back door,
and then do something like turn on a message lamp on the telephones (I'm
thinking PBX here, but also consider that deregulation of local switching
will result in some amount of "neighborhood telcos" using PBXs to resell
service...)   Remote access means that some kind of signal has to be sent to
the PBX to turn on the tap, either via normal trunks or some signalling
channel.  

Re. John Draper's item about cost of complete RNGs as being 4x the parts
cost: that is a standard figure I've seen in use many times.  Covers labor
and overhead expenses, including parts for prototypes which fail, and all
that.  COmpletely reasonable estimate.  Though it would still be nice to
find a less expensive way to do this.  

Now that I think of it, I believe that Billy Sq-you-know-who designed one of
these for me many years ago for exactly this purpose, based on discrete
components... and anyone here who knows Bill knows the quality of his
designs... so if I can dig up that piece of paper, I'll see about bringing
it along to one of our meetings (he drew out a complete schematic).

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Thu, 12 Nov 92 03:03:12 PST
To: cypherpunks@toad.com
Subject: Mac PGP - Some comments
Message-ID: <9211121059.AA11389@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


   I seem to be having problems using the Mac version of PGP,  in that
when I type ANY character into it,  I just get a "beep".   Is there
some other thing I have to do to get this thing to work?    I also
want to start building by public key ring so I can learn how to use
this puppie,  but I am concerned with possible legal problems in
using this to communicate with my friends.   According to the disclaimer,
PGP is "contraband"?    Will I get the "thought police" busting down
my door for using it?

    Is anyone working on a Mac version that is more Mac'ish?   Like
putting in a nice Mac like GUI for key management.    It would be nice
if it had a pub (or private) "key list" in an editable scrollable list.

    The Mac version in "mac.archive.umich.edu" appears with just a 
"cheapie" console window that behaves like I described above.    If I
had source code,   I could "wrap it" in a nice Object oriented GUI
and maintain the file format for the keys.

    Thanx Eric for the Email address for Zbigniew Fiedorowicz.   

    Has anyone contacted Zbigniew relating to the Mac port?   It appears
to have some problems,   but time limitations has prevented me from
fiddling with it tonight.    I think I might actually have access to the
Nets tommorrow,   so I'll be "on-line".

Cheers
JD





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Thu, 12 Nov 92 03:07:32 PST
To: tcmay@netcom.com
Subject: Re:  (fwd) A Silver Bullet to Limit Crypto?
Message-ID: <199211121106.AA25693@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Regarding key registration proposals.  

Tim's critiques shed a most interesting light on this problem.  They also
point to parallels with voter registration:

It has been well-known for some time that requiring people to register some
time in advance of an election, causes a decline in participation.  This
decline is most evident among the disadvantaged sector of the population,
for various reasons including inability to take time off from work.  Were
the disadvantaged to vote en masse, they would most likely weigh in on the
side of substantial change, particularly change which would shift the
balance of power in a more socially equitable direction.  As the
powers-that-be prefer to maintain the status quo, they are quite satisfied
with the fact that the disadvantaged aren't voting in larger numbers.
Hence Republican administrations have (in recent history) blocked efforts to
simplify and ease voter registration, as for instance the "motor voter bill"
which would automatically create a voter registration when someone gets a
driver's licence or car registration.

The United States is the world's only remaining Western democracy which
requires advance voter registration.  This practice had its roots in
attempts to prevent newly naturalised US citizens from voting, again, the
result of prejudice and desire to maintain the status quo.  Now that the
Dems are in power, we might consider tying the crypto key issue to the
elimination of voter registration, on the basis that both voting and digital
communication are forms of speech which should not be subjected to a
chilling effect.  

Rapid promulgation of decent user-friendly PKSs looks pretty essential at
this point.  I'm thinking, how about approaching Apple to see if they'll
include a PKS along with their Macs, as bundled software, sort of like
Hypercard.  Even if the PKS which is used, has some problem with is, as for
instance the old trapdoor-knapsack system, **anything** is preferable to
nothing at all when it comes to getting the public educated.  Does anyone
here know any of the main people at Apple...?  What do you think they'd have
to say about bundling privacy software along with Macs?

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 12 Nov 92 07:57:00 PST
To: cypherpunks@toad.com
Subject: (fwd) A Silver Bullet to Limit Crypto?
In-Reply-To: <199211121106.AA25693@well.sf.ca.us>
Message-ID: <9211121557.AA25427@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: tying voter and crypto registration issues togther.

An excellent idea, if both succeed.  But since voter registration is
already a partisan issue, tying crypto registration to it make crypto
a partisan issue.  And once you've made it a partisan issue, you've
lost, fundamentally.  

The way to succeed on any issue is to avoid polarization along party
lines.  One should not assume that there will be automatically a large
opposition.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 12 Nov 92 07:59:57 PST
To: cypherpunks@toad.com
Subject: (fwd) A Silver Bullet to Limit Crypto?
In-Reply-To: <199211121106.AA25693@well.sf.ca.us>
Message-ID: <9211121600.AA25453@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Re: Apple include a PKS with their Macs

Well, Apple does have a site license for RSA.  Tim Oren, who's on the
list, knows more about this than I.  I ask him to respond.

Maybe Apple could license the PGP code as a system utility?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: simsong@next.cambridge.ma.us (Simson L. Garfinkel)
Date: Thu, 12 Nov 92 07:24:57 PST
To: George A. Gleason <gg@well.sf.ca.us>
Subject: Re: (fwd) A Silver Bullet to Limit Crypto?
Message-ID: <9211121334.AA08156@next.cambridge.ma.us>
MIME-Version: 1.0
Content-Type: text/plain


Hi.  I'm new to this list.  Some people may know me.

> Date: Thu, 12 Nov 1992 03:06:19 -0800
> From: George A. Gleason <gg@well.sf.ca.us>
> To: cypherpunks@toad.com, tcmay@netcom.com
> Subject: Re:  (fwd) A Silver Bullet to Limit Crypto?
> 

> Now that the
> Dems are in power, we might consider tying the crypto key issue to the
> elimination of voter registration, on the basis that both voting and digital
> communication are forms of speech which should not be subjected to a
> chilling effect.  

> 


Good luck.  As a practicing journalist, I can say that there is no way that I  
could make this argument in print.  Everybody understand voter registration.   
There's support for the motor-voter bill.  I can't even explain cryptography in  
the same amount of time that it takes to do an entire article on voter  
registration.

There may be a theoretical connection between the two, but you'll never make  
that argument outside a university.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 12 Nov 92 09:45:09 PST
To: cypherpunks@toad.com
Subject: random generator
In-Reply-To: <9211121612.AA03658@newsu.shearson.com>
Message-ID: <9211121745.AA27478@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>I'd like to point out that higher data rates are very very desirable.

And higher data rates are more expensive.  If you're making one time
pads, you need high bit rates, but otherwise you don't.  10Kbps is
overcapacity for personal use.

Let's do an estimate.  Suppose all you use your random numbers for is
to create session keys for socket connections.  Now lets say you need
to open a socket about once a minute.  Since you need, say, 500 bits
for a DH key exchange, that's a bit rate of about 10 bits per second.

One can cache bits coming in from the random number generator in a
ring buffer.  You can make this ring buffer arbitarily large, or even
virtualize it to disk and make it appear as infinite in size.  Then
you could run your generator continuously and always have enough bits
available for use.

If you're using a generator for making session keys, then you just
don't need that high a bandwidth.  

Now the $/bps for the Newbridge chip is much lower, but for personal
use you throw away too many of its bits to make it worthwhile.  This
higher bandwidth chip would be useful in a server of some sort, where
you are making session keys more than once per second.

Proposal: Make this random number generator operate at 100 bps.  If
higher bit rates are the same price, fine.  But a specific design
criterion of 100 bps should be a practical and economical goal.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Thu, 12 Nov 92 08:38:19 PST
To: crunch@netcom.com
Subject: My responses regarding random generator.
In-Reply-To: <9211112152.AA24329@netcom2.netcom.com>
Message-ID: <9211121612.AA03658@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: crunch@netcom.com (John Draper)

>   Then,  there is the speed of generating these random numbers,
>and how we will want to deal with the possibility of inadequate
>speed.     I suspect that serial transmission at 9500 baud might
>be easily obtained,   but going much faster withoug "drift" might 
>be problematic as Tim May pointed out.

I'd like to point out that higher data rates are very very desirable.
One would like to be able to cut a pair of CD's for use as one time
pads in a reasonable amount of time -- at 9600 baud its going to take
a LONG time to do. You can always run multiple units in parallel, but
its probably good to get the cost/bitrate ratio as low as possible.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Barry.Kapke@f33.n125.z1.FIDONET.ORG (Barry Kapke)
Date: Thu, 12 Nov 92 12:39:29 PST
To: cypherpunks@toad.com
Subject: cypherpunk-request
Message-ID: <3585.2B02B9C5@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain




This is a request to be added to the mailing list. My addressing to cypherpunk-request@toad.com failed. Thanks.


 :::::::::::::::::::::::::::::::::::
 Barry.Kapke@f33.n125.z1.FIDONET.ORG
 :::::::::::::::::::::::::::::::::::
--  
Barry Kapke - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!33!Barry.Kapke
INTERNET: Barry.Kapke@f33.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: omega@spica.bu.edu (The Omega)
Date: Thu, 12 Nov 92 09:51:33 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9211121751.AA01503@spica.bu.edu>
MIME-Version: 1.0
Content-Type: text/plain




---- article one ----
Subject: Reports of "Raid" on 2600 Washington Meeting 11/09/92
From: newsbytes@clarinet.com
Date: 9 Nov 92 20:51:16 GMT

WASHINGTON, D.C., U.S.A., 1992 NOV 9 (NB) -- The publisher of
a well-known hacker magazine claims a recent meeting attended by
those interested in the issues his magazine raises was disrupted
by threats of arrest by security and Arlington, Virginia
police officers.

Eric Corley, also known as "Emmanuel Goldstein," editor and publisher
of "2600 Magazine: The Hacker Quarterly," told Newsbytes that the
meeting was held November 6th at the Pentagon City Mall
outside Washington, DC was disrupted and material was confiscated
in the raid.

2600 Magazine promotes monthly meetings of hackers, press, and other
interested parties throughout the country. The meetings are held in public
locations on the first Friday evening of the month and the groups often
contact each other by telephone during the meetings.

Corley told Newsbytes that meetings were held that evening in New
York, Washington, Philadelphia, Cambridge, St. Louis, Chicago,
Los Angeles and San Francisco. Corley said, "While I am sure that
meetings have been observed by law enforcement agencies, this is
the only time that we have been harassed. It is definitely a
freedom of speech issue."

According to Craig Neidorf, who was present at the meeting and was
distributing applications for membership in Computer Professionals
For Social Responsibility (CPSR), "I saw the security officers focusing
on us. Then they started to come toward us from a number of
directions under what seemed to be the direction of a person with
a walkie-talkie on a balcony. When they approached, I left the
group and observed the security personnel encircling the group of
about 30 gatherers. The group was mainly composed of high
school and college students. The guards demanded to search the knapsacks
and bags of the gatherers. They confiscated material, including CPSR
applications, a copy of Mondo 2000 (a magazine), and other material."

He adds that the guards also confiscated film "from a person trying
to take pictures of the guards. When a hacker called "HackRat"
attempted to copy down the names of the guards, they took his
pencil and paper."

Neidorf continued, "I left to go outside and rejoined the group when they
were ejected from the mall. The guards continued challenging the group
and told them that they would be arrested if they returned. When one of
the people began to take pictures of the guards, the apparent supervisor
became excited and threatening but did not confiscate the film."

Neidorf also said, "I think that the raid was planned. They hit right about
6:00 and they identified our group as "hackers" and said that they knew
that this group met every month."

Neidorf's story was supported by a Washington "hacker" called "Inhuman,"
who told Newsbytes, "I arrived at the meeting late and saw the group being
detained by the guards. I walked along with the group as they were being
ushered out and when I asked a person who seemed to be in authority his
name, he pointed at a badge with his name written in script on it.
I couldn't make out the name and, when I mentioned that to the person,
he said 'If you can't read it, too bad.' I did read his name,
'C. Thomas,' from another badge."

Inhuman also told Newsbytes that he was told by a number of people
that the guards said that they were "acting on behalf of the
Secret Service." He added, "I was also told that there were two
police officers from the Arlington County Police present but I
did not see them."

Another attendee, Doug Luce, reports, "I also got to the DC
meeting very late; 7:45 or so. It seemed like a coordinated harassment
episode, not geared toward busting anyone, but designed to get people
riled up, and maybe not come back to the mall."

Luce adds that he overheard a conversation between someone who had
brought a keyboard to sell. The person, he said, was harassed by
security forces, one of whom said, "You aren't selling anything in
my mall without a vendors permit!"

Possible Secret Service involvement was supported by a 19 year-old
college student known as the "Lithium Bandit," who told
Newsbytes, "I got to the mall about 6:15 and saw the group being detained
by approximately 5 Arlington County police and 5 security guards. When I
walked over to see what was going on, a security guard asked me for an ID
and I refused to show it, saying that I was about to leave. The guard
said that I couldn't leave and told me that I had to see a police
officer. When I did, the officer demanded ID and, when I once again
refused, he informed me that I could be detained for up to 10 hours
for refusing to produce identification. I gave in and produced my
school ID which the police gave to the security people who copied
down my name and social security number."

Lithium Bandit continued, "When I asked the police what was behind this
action, I was told that they couldn't answer but that 'the Secret
Service is involved and we are within our rights doing this."

The boy says he and others later went to the Arlington police station
to get more information and were told only that there was a report
of the use of a stolen credit card and two officers were sent to
investigate. "They later admitted that it was 5 [officers]. While I was
detained, I heard no mention of a credit card and there was no one
arrested."

Marc Rotenberg, director of CPSR's Washington office, told Newsbytes, "I
have really no details on the incident yet but I am very concerned
about the reports. Confiscation of CPSR applications, if true, is
outrageous. I will find out more facts on Monday."

Newsbytes was told by the Pentagon City Mall office that any information
concerning the action would have to come from the director of security, Al
Johnson, who was not available until Monday. The Arlington Country
Police referred Newsbytes to a "press briefing recording" which had not
been updated since the morning before the incident.

Corley told Newsbytes, "There have been no reports of misbehavior by any
of these people. They were obviously singled out because they were
hackers. It's as if they were being singled out as an ethnic group. I
admire the way the group responded -- in a courteous fashion. But it
is inexcusable that it happened. I will be at the next Washington
meeting to insure that it doesn't happen again."

The manager of one of New York state's largest malls provided
background information to Newsbytes on the rights of malls to police those
on mall property, saying, "The primary purpose of a mall is to sell. The
interior of the mall is private property and is subject to the
regulations of the mall. The only requirement is that the regulations
be enforced in an even-handed manner. I do not allow political
activities in my mall so I could not make an exception for Democrats.
We do allow community groups to meet but they must request space at
least two weeks before the meeting and must have proper insurance.
Our regulations also say that groups of more than 4 may not congregate
in the mall."

The spokeswoman added that mall security can ask for identification
from those who violate regulations and that they may be barred from the
mall for a period of 6 months.

She added, "Some people feel that mall atriums and food courts are public
space. They are not and the industry is united on this. If the malls were
to receive tax benefits for the common space and public service in snow
removal and the like, it could possibly be a public area but malls are taxed
on the entire space and are totally private property, subject to their own
regulations. If a group of 20 or more congregated in my mall, they would
be asked to leave."

---- article two ----
Subject: Secret Service Role Questioned in "2600 Washington Raid" 11/10/92
From: newsbytes@clarinet.com
Date: 10 Nov 92 21:03:23 GMT

WASHINGTON, D.C., U.S.A., 1992 NOV 10 (NB) -- In the aftermath of an
action on Friday, November 6th by members of the Pentagon City Mall
Police and police from Arlington County, VA in which those attending a
2600 meeting at the mall were ordered from the premises, conflicting
stories continue to appear.

Attendees at the meeting have contended to Newsbytes that members of
the mall police told them that they were "acting on behalf of the
Secret Service." They also maintain that the mall police confiscated
material from knapsacks and took film from someone attempting to
photograph the action and a list of the names of security officers
that one attendee was attempting to compile.

Al Johnson, chief of security for the mall, denied these allegations
to Newsbytes, saying, "No one said that we were acting on behalf of
the Secret Service. We were merely enforcing our regulations. While
the group was not disruptive, it had pulled tables together and was
having a meeting in our food court area. The food court is for
people eating and is not for meetings. We therefore asked the
people to leave."

Johnson denied that security personnel took away any film or lists
and further said: "We did not confiscate any material. The group
refused to own up to who owned material on the tables and in the
vicinity so we collected it as lost material. If it turns out
that anything did belong to any of those people, they are welcome
to come in and, after making proper identification, take the
material."

In a conversation early on November 9th, Robert Rasor, Secret Service
agent-in-charge of computer crime investigations, told Newsbytes that
having mall security forces represent the Secret Service is not
something that was done and, that to his knowledge, the Secret
Service had no involvement with any Pentagon City mall actions
on the previous Friday.

A Newsbytes call to the Arlington County police was returned by a
Detective Nuneville who said that her instructions were to refer all
questions concerning the matter to agent David Adams of the Secret
Service. She told Newsbytes that Adams would be providing all
information concerning the involvement of both the Arlington Police and
the Secret Service in the incident.

Adams told Newsbytes: "The mall police were not acting as agents
for the Secret Service. Beyond that, I can not confirm or deny
that there is an ongoing investigation."

Adams also told Newsbytes that: "While I cannot speak for the
Arlington police, I understand that their involvement was due to
an incident unrelated to the investigation."

Marc Rotenberg, director of the Washington office of Computer
Professionals for Social Responsibility (CPSR), told Newsbytes
that "CPSR has reason to believe that the detention of people at
the Pentagon City Mall last Friday was undertaken at the behest
of the Secret Service, which is a federal agency."

"If that is the case, then there was an illegal search of people
at the mall. There was no warrant and no indication of probable
illegal activity. This raises constitutional issues. We have
undertaken the filing of a Freedom of Information Act (FOIA)
request to determine the scope, involvement and purpose of the
Secret Service in this action," he said.

2600 meetings are held on the evening of the first Friday of each
month in public places and malls in New York City, Washington,
Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San
Francisco. They are promoted by "2600 Magazine: The Hacker Quarterly"
and are attended by a variety of persons interested in
telecommunications and so-called "hacker issues."

The New York meeting, the oldest of its kind, is regularly attended
by Eric Corley a/k/a Emmanuel Goldstein, editor and publisher of 2600,
hackers, journalists, corporate communications professionals and other
interested parties. It is known to have been the subject of
surveillance at various times by law enforcement agencies conducting
investigations into allegations of computer crime.

Corley told Newsbytes: "While I'm sure that meetings have been
observed by law enforcement agencies, this is the only time that
we have been harassed. It's definitely a freedom of speech
issue." Corley also that he plans to be at the December meeting
in Washington "to insure that it doesn't happen again."





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: omega@spica.bu.edu (The Omega)
Date: Thu, 12 Nov 92 10:50:30 PST
To: cypherpunks@toad.com
Subject: DC 2600 -- Secret Service Involvement?
Message-ID: <9211121850.AA01807@spica.bu.edu>
MIME-Version: 1.0
Content-Type: text/plain


For more info, see the recent Computer Underground Digest.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Thu, 12 Nov 92 13:52:59 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9211122154.AA13213@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


I have a new address where I am running a cryptographically
protected, anonymous remailer based on Eric Hughes' perl scripts.

It is: <hal@alumni.caltech.edu>.

To use the server, put "Request-Remailing-To: <destination-address>"
into the header of the message, and send it to the above address.  If
your mailer won't let you put things into message headers, instead make
the first line of your message body be just the two characters "::",
and make the next line be "Request-Remailing-To: <destination-address>",
and make the next line be blank.  The "::" tells the remailer to take
the following lines, up to a blank one, and put them into the header.

This particular remailer has PGP integrated into it so that you can
encrypt your messages to the remailer.  That way a snooper can't see
the "Request-Remailing-To" information and can't tell who you are
sending to.

To use this feature, create a message and put "::" and
"Request-Remailing-To:" lines at the beginning, followed by a blank
line.  Then encrypt this whole message, including these extra lines,
using PGP with the remailer key below.  (Remember to use the -a flag
for ASCII output.)

Now, you have to do one more thing.  You have to put "Encrypted: PGP"
into the message header when you send this message.  Again, if you
can't put stuff into message headers, you have to edit the PGP ASCII
output file to add a line of "::", then a line saying "Encrypted: PGP",
then a blank line.  This can then be sent to the address above.  It
will decrypt the message, find the "Request-Remailing-To" line, and
forward it for you.

This machine is on the Internet so it should have nice, fast
turnaround.

Be aware that this is a multi-user machine so the encryption is not
super secure.  Don't bet your life on these messages not being broken.
This is strictly experimental at this time.

If anyone would like help getting PGP or one of these remailers
operating on your local Unix machine, let me know and I will offer any
advice that I can.  I would really like to see more people than just
Eric and myself running remailers.

There is a more advanced capability made possible by the cryptographic
remailer, which is an "anonymous return address."  The idea is, I can
post to a group like this, or a usenet group, using a pseudonym.  I
also include my anonymous return address, which is basically my
regular return address, encrypted using the public key of a remailer.
People can use this anonymous return address to send to me by
forwarding it through the remailer, which decrypts the address, finds
out who I am, and sends it to me.  The people communicating to me
don't even have to know who I am, or what my email address is.  Two
people could communicate using email, with both of their identities
being protected from the other.  This kind of capability can really
be important in crypto-privacy.

Hal
74076.1041@compuserve.com

P.S. Here is the PGP key for this remailer:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.01

mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi
T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2
aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg==
=K00H
-----END PGP PUBLIC KEY BLOCK-----




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bob Stratton <strat@intercon.com>
Date: Thu, 12 Nov 92 11:28:41 PST
To: cypherpunks@toad.com
Subject: DC 2600 mtg
Message-ID: <9211121425.AA32211@horton.intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


Hi all...

I was at the latter part of the Washington 2600 meeting, feel free to ask me 
questions if you want.

By the way, today's article about the event was yet another example of the 
media promoting hysteria about technologically competent people. The whole 
article was of the "A hacker is someone who breaks into systems" model. It 
makes me sick, and I think that the crypto community (the part NOT employed 
by DoD) is next for this sort of misrepresentation.

Cheers,
Bob Stratton     Engineer, InterCon Systems Corp.     strat@intercon.com
+1 703 709 5525 (W) 






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gsassoun@shearson.com (Garo Sassouni)
Date: Thu, 12 Nov 92 12:34:29 PST
To: cypherpunks@toad.com
Subject: Subscribe
Message-ID: <9211122007.AA15091@tardis.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


I would like to subscribe to the cypherpunks group.

Thanks in advance




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Thu, 12 Nov 92 14:28:48 PST
To: cypherpunks@toad.com
Subject: re: Re:  (fwd) A Silver Bullet to Limit Crypto?
Message-ID: <3587.2B02D6F4@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: gg@well.sf.ca.us (George A. Gleason)

 U> Rapid promulgation of decent user-friendly PKSs looks 
 U> pretty essential at this point.  I'm thinking, how about 
 U> approaching Apple to see if they'll include a PKS along 
 U> with their Macs, as bundled software, sort of like 
 U> Hypercard.  Even if the PKS which is used, has some 
 U> problem with is, as for instance the old trapdoor-knapsack 
 U> system, **anything** is preferable to nothing at all when 
 U> it comes to getting the public educated.

I agree 101% -- I'd rather have a "bad" system in place, with people
asking for a good one (and roundly complaining about the short-sighted
implementors :-) than to sit and wait until we can implement the
"right" system.

I'd much rather have email users want privacy and rag about their
compromised system. Even a relatively poor one buts some substantial
blocks into routine bulk monitoring of traffic...

As frequently happens, the real problem is not technical.

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems  (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Thu, 12 Nov 92 13:18:01 PST
Subject: No Subject
Message-ID: <9211122117.AA29329@iha.compuserve.com>
MIME-Version: 1.0
Content-Type: text/plain



Bcc: Blind Recipients List:;
Subject: Why hardware random numbers?
Message-ID: <921112211037_74076.1041_DHJ46-1@CompuServe.COM>

I don't understand the desire for hardware-based random number generators.
It seems to me that a decent software RNG would be adequate for
the main uses that I have heard of for RNG's (mostly session key
generation).

Seed the RNG initially with a nice random set of characters typed in
by the user, plus timing information based on the rate of timing of
those characters.  Also use the local system clock, and possibly a
hash of some sectors of the disk or some files on /tmp.  Create a pool
of random numbers in this way.

As you use them, refill the pool, making the refilled bytes a function
of the current system clock, and whatever message you are encrypting
(or some other appropriate global state).

Use a nice strong RNG based on DES, MD5, IDEA, or some other cypher or
hash function.

I don't think anyone could break the resulting random stream without
a physical attack on your computer.  Why pay $50 to $200 for a hardware
device when you can get the same effect in software that already exist?
Both PGP and RIPEM, I think, use the above techniques for their random
numbers.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 12 Nov 92 16:21:35 PST
To: cypherpunks@toad.com
Subject: The Crypto Singularity
Message-ID: <9211130018.AA11046@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



We appear to be entering the long-awaited "Crypto Singularity." (Well,
long-awaited by me at least!) A "singularity" in the sense of
extremely rapid changes in outlook, technology, and culture. (The use
comes from Vernor Vinge's science fictional "singularity" in new
technologies, as described in "Marooned in Realtime," and appropriated
for their own purposes by the nanotechnology enthusiasts.)

Some evidence for this "Crypto Singularity":

* the appearance of fully-encrypted remailers, using the Perl scripts
of Eric Hughes and Hal Finney. With several more such remailing sites
(and recall John Little's offer to place the s/w on Portal), a
critical mass of remailers may exist. (A packet remailed through 10
remailers, each storing 10 such encrypted packets before remailing,
has an intrinsic diffusivity of 10^10. Of course, there will be far
fewer than 10 billion messages, but the point is clear that the origin
of a message is effectively untraceable.) 

* the spread of PGP, onto Internet sites, FidoNet, and hacker boards,
IRCs, and the like. (I expect the adoption of PGP by the phone
hacker/phreaker community--the community so far the main target of
formal charges, as in the Legion of Doom, Len Rose, and Sun Devil
cases--is setting off alarms in the law enforcement community.)

* the "Hacker Crackdown" spreading to "2600" (will Cyperpunks be next?
Will the 150-200 of us get raided?) and mere _meetings_ of hacker
folks.

* the incredible excitement over these topics at the Hackers
Conference, with the sense that these are no longer just abstract
ideas.

* the interest by several journalists in covering these matters (more
on this if things develop).

* articles in "Scientific American" just in the past
months...David Chaum's work on digital cash, and quantum cryptography.

* the firestorm of comments (over 500) about the proposal to register
cryptographic keys. 

All of these point to an accelerating situation. Things may get very
interesting and very sticky in the next several months, which is quite
a bit faster than I'd expected.

Justice and the FBI may not wait until the next Administration to get
something started. Perhaps a high-publicity case involving drugs or
child molestors will be used as a pretext to crack down. This
crackdown may not need new laws...the existing conspiracy, RICI Act,
and espionage laws may be enough to "set some examples."

Our next Cypherpunks meeting (Saturday, 21 November) should look at
some of these issues. "Time is of the essence."

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: romkey@asylum.sf.ca.us (John Romkey)
Date: Thu, 12 Nov 92 15:15:16 PST
To: cypherpunks@TOAD.COM
Subject: Re:  (fwd) A Silver Bullet to Limit Crypto?
In-Reply-To: <3587.2B02D6F4@fidogate.FIDONET.ORG>
Message-ID: <9211122315.AA09487@asylum.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


   Date: Thu, 12 Nov 92 15:09:47 PDT
   From: Tom.Jennings@F111.N125.Z1.FIDONET.ORG (Tom Jennings)

   I'd much rather have email users want privacy and rag about their
   compromised system. Even a relatively poor one buts some substantial
   blocks into routine bulk monitoring of traffic...

As long as they *know* it's compromised. Too many people out there
think the Internet, for instance, is secure already. They don't
realize how easily one can spy on their email, or find out if they're
subscribed to a mailing list.
	- john romkey	  ELF Communications	 romkey@ELF.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: omega@spica.bu.edu (The Omega)
Date: Thu, 12 Nov 92 15:33:56 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9211122333.AA03023@spica.bu.edu>
MIME-Version: 1.0
Content-Type: text/plain




---- article one ----
Subject: Reports of "Raid" on 2600 Washington Meeting 11/09/92
From: newsbytes@clarinet.com
Date: 9 Nov 92 20:51:16 GMT

WASHINGTON, D.C., U.S.A., 1992 NOV 9 (NB) -- The publisher of
a well-known hacker magazine claims a recent meeting attended by
those interested in the issues his magazine raises was disrupted
by threats of arrest by security and Arlington, Virginia
police officers.

Eric Corley, also known as "Emmanuel Goldstein," editor and publisher
of "2600 Magazine: The Hacker Quarterly," told Newsbytes that the
meeting was held November 6th at the Pentagon City Mall
outside Washington, DC was disrupted and material was confiscated
in the raid.

2600 Magazine promotes monthly meetings of hackers, press, and other
interested parties throughout the country. The meetings are held in public
locations on the first Friday evening of the month and the groups often
contact each other by telephone during the meetings.

Corley told Newsbytes that meetings were held that evening in New
York, Washington, Philadelphia, Cambridge, St. Louis, Chicago,
Los Angeles and San Francisco. Corley said, "While I am sure that
meetings have been observed by law enforcement agencies, this is
the only time that we have been harassed. It is definitely a
freedom of speech issue."

According to Craig Neidorf, who was present at the meeting and was
distributing applications for membership in Computer Professionals
For Social Responsibility (CPSR), "I saw the security officers focusing
on us. Then they started to come toward us from a number of
directions under what seemed to be the direction of a person with
a walkie-talkie on a balcony. When they approached, I left the
group and observed the security personnel encircling the group of
about 30 gatherers. The group was mainly composed of high
school and college students. The guards demanded to search the knapsacks
and bags of the gatherers. They confiscated material, including CPSR
applications, a copy of Mondo 2000 (a magazine), and other material."

He adds that the guards also confiscated film "from a person trying
to take pictures of the guards. When a hacker called "HackRat"
attempted to copy down the names of the guards, they took his
pencil and paper."

Neidorf continued, "I left to go outside and rejoined the group when they
were ejected from the mall. The guards continued challenging the group
and told them that they would be arrested if they returned. When one of
the people began to take pictures of the guards, the apparent supervisor
became excited and threatening but did not confiscate the film."

Neidorf also said, "I think that the raid was planned. They hit right about
6:00 and they identified our group as "hackers" and said that they knew
that this group met every month."

Neidorf's story was supported by a Washington "hacker" called "Inhuman,"
who told Newsbytes, "I arrived at the meeting late and saw the group being
detained by the guards. I walked along with the group as they were being
ushered out and when I asked a person who seemed to be in authority his
name, he pointed at a badge with his name written in script on it.
I couldn't make out the name and, when I mentioned that to the person,
he said 'If you can't read it, too bad.' I did read his name,
'C. Thomas,' from another badge."

Inhuman also told Newsbytes that he was told by a number of people
that the guards said that they were "acting on behalf of the
Secret Service." He added, "I was also told that there were two
police officers from the Arlington County Police present but I
did not see them."

Another attendee, Doug Luce, reports, "I also got to the DC
meeting very late; 7:45 or so. It seemed like a coordinated harassment
episode, not geared toward busting anyone, but designed to get people
riled up, and maybe not come back to the mall."

Luce adds that he overheard a conversation between someone who had
brought a keyboard to sell. The person, he said, was harassed by
security forces, one of whom said, "You aren't selling anything in
my mall without a vendors permit!"

Possible Secret Service involvement was supported by a 19 year-old
college student known as the "Lithium Bandit," who told
Newsbytes, "I got to the mall about 6:15 and saw the group being detained
by approximately 5 Arlington County police and 5 security guards. When I
walked over to see what was going on, a security guard asked me for an ID
and I refused to show it, saying that I was about to leave. The guard
said that I couldn't leave and told me that I had to see a police
officer. When I did, the officer demanded ID and, when I once again
refused, he informed me that I could be detained for up to 10 hours
for refusing to produce identification. I gave in and produced my
school ID which the police gave to the security people who copied
down my name and social security number."

Lithium Bandit continued, "When I asked the police what was behind this
action, I was told that they couldn't answer but that 'the Secret
Service is involved and we are within our rights doing this."

The boy says he and others later went to the Arlington police station
to get more information and were told only that there was a report
of the use of a stolen credit card and two officers were sent to
investigate. "They later admitted that it was 5 [officers]. While I was
detained, I heard no mention of a credit card and there was no one
arrested."

Marc Rotenberg, director of CPSR's Washington office, told Newsbytes, "I
have really no details on the incident yet but I am very concerned
about the reports. Confiscation of CPSR applications, if true, is
outrageous. I will find out more facts on Monday."

Newsbytes was told by the Pentagon City Mall office that any information
concerning the action would have to come from the director of security, Al
Johnson, who was not available until Monday. The Arlington Country
Police referred Newsbytes to a "press briefing recording" which had not
been updated since the morning before the incident.

Corley told Newsbytes, "There have been no reports of misbehavior by any
of these people. They were obviously singled out because they were
hackers. It's as if they were being singled out as an ethnic group. I
admire the way the group responded -- in a courteous fashion. But it
is inexcusable that it happened. I will be at the next Washington
meeting to insure that it doesn't happen again."

The manager of one of New York state's largest malls provided
background information to Newsbytes on the rights of malls to police those
on mall property, saying, "The primary purpose of a mall is to sell. The
interior of the mall is private property and is subject to the
regulations of the mall. The only requirement is that the regulations
be enforced in an even-handed manner. I do not allow political
activities in my mall so I could not make an exception for Democrats.
We do allow community groups to meet but they must request space at
least two weeks before the meeting and must have proper insurance.
Our regulations also say that groups of more than 4 may not congregate
in the mall."

The spokeswoman added that mall security can ask for identification
from those who violate regulations and that they may be barred from the
mall for a period of 6 months.

She added, "Some people feel that mall atriums and food courts are public
space. They are not and the industry is united on this. If the malls were
to receive tax benefits for the common space and public service in snow
removal and the like, it could possibly be a public area but malls are taxed
on the entire space and are totally private property, subject to their own
regulations. If a group of 20 or more congregated in my mall, they would
be asked to leave."

---- article two ----
Subject: Secret Service Role Questioned in "2600 Washington Raid" 11/10/92
From: newsbytes@clarinet.com
Date: 10 Nov 92 21:03:23 GMT

WASHINGTON, D.C., U.S.A., 1992 NOV 10 (NB) -- In the aftermath of an
action on Friday, November 6th by members of the Pentagon City Mall
Police and police from Arlington County, VA in which those attending a
2600 meeting at the mall were ordered from the premises, conflicting
stories continue to appear.

Attendees at the meeting have contended to Newsbytes that members of
the mall police told them that they were "acting on behalf of the
Secret Service." They also maintain that the mall police confiscated
material from knapsacks and took film from someone attempting to
photograph the action and a list of the names of security officers
that one attendee was attempting to compile.

Al Johnson, chief of security for the mall, denied these allegations
to Newsbytes, saying, "No one said that we were acting on behalf of
the Secret Service. We were merely enforcing our regulations. While
the group was not disruptive, it had pulled tables together and was
having a meeting in our food court area. The food court is for
people eating and is not for meetings. We therefore asked the
people to leave."

Johnson denied that security personnel took away any film or lists
and further said: "We did not confiscate any material. The group
refused to own up to who owned material on the tables and in the
vicinity so we collected it as lost material. If it turns out
that anything did belong to any of those people, they are welcome
to come in and, after making proper identification, take the
material."

In a conversation early on November 9th, Robert Rasor, Secret Service
agent-in-charge of computer crime investigations, told Newsbytes that
having mall security forces represent the Secret Service is not
something that was done and, that to his knowledge, the Secret
Service had no involvement with any Pentagon City mall actions
on the previous Friday.

A Newsbytes call to the Arlington County police was returned by a
Detective Nuneville who said that her instructions were to refer all
questions concerning the matter to agent David Adams of the Secret
Service. She told Newsbytes that Adams would be providing all
information concerning the involvement of both the Arlington Police and
the Secret Service in the incident.

Adams told Newsbytes: "The mall police were not acting as agents
for the Secret Service. Beyond that, I can not confirm or deny
that there is an ongoing investigation."

Adams also told Newsbytes that: "While I cannot speak for the
Arlington police, I understand that their involvement was due to
an incident unrelated to the investigation."

Marc Rotenberg, director of the Washington office of Computer
Professionals for Social Responsibility (CPSR), told Newsbytes
that "CPSR has reason to believe that the detention of people at
the Pentagon City Mall last Friday was undertaken at the behest
of the Secret Service, which is a federal agency."

"If that is the case, then there was an illegal search of people
at the mall. There was no warrant and no indication of probable
illegal activity. This raises constitutional issues. We have
undertaken the filing of a Freedom of Information Act (FOIA)
request to determine the scope, involvement and purpose of the
Secret Service in this action," he said.

2600 meetings are held on the evening of the first Friday of each
month in public places and malls in New York City, Washington,
Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San
Francisco. They are promoted by "2600 Magazine: The Hacker Quarterly"
and are attended by a variety of persons interested in
telecommunications and so-called "hacker issues."

The New York meeting, the oldest of its kind, is regularly attended
by Eric Corley a/k/a Emmanuel Goldstein, editor and publisher of 2600,
hackers, journalists, corporate communications professionals and other
interested parties. It is known to have been the subject of
surveillance at various times by law enforcement agencies conducting
investigations into allegations of computer crime.

Corley told Newsbytes: "While I'm sure that meetings have been
observed by law enforcement agencies, this is the only time that
we have been harassed. It's definitely a freedom of speech
issue." Corley also that he plans to be at the December meeting
in Washington "to insure that it doesn't happen again."





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: omega@spica.bu.edu (The Omega)
Date: Thu, 12 Nov 92 15:34:46 PST
To: cypherpunks@toad.com
Subject: IRC Bot
Message-ID: <9211122334.AA03027@spica.bu.edu>
MIME-Version: 1.0
Content-Type: text/plain


On a related tangent, There's an interesting bot on IRC
in the #hack room, called MACE0, whose purpose is:


>>
mACe0 exists primarily to accept requests for access to a secure
mailing list but it performs other mundane functions as well. To
apply for access to the mACe0 mailing list you need to do three
things.  First, get PGP up and running on your system so that you
can generate RSA public keys.  Second, get one of the questionaires
listing below so u can fill it out.  As with all classic elite k-rad
systems, we have to know your capabilities and limits so that we can
appropriately deny your access. If this bothers you, too bad; the
old school k-rad d00dz have seen this type of bullshit before and know
exactly what to do.  Finally, use mACe0's public key to encrypt
your Questionaire and DCC it to mACe0.  mACe0 will also take
article submissions and public keys via DCC; both of which should be
encrypted with mACe0's public key.


*Note, when submitting public keys:
        a)   use pgp -kxa to extract them in ascii.
        b)   use a fairly unique filename so DCC won't overwrite
             your key.


/msg mACe0 info                 .Display this file again.
/msg mACe0 dir                  .Dir of files available
/msg mACe0 get filename         .To get a file


/msg mACe0 sendkey              .DCCs mACe0's public key
/msg mACe0 quest.1              .Get Hack specific Questionaire
/msg mACe0 quest.2              .Get Phreak specific Questionaire
/msg mACe0 quest.3              .Get Phreak/Hack mixed Questioniare
<<




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Mitra <mitra@pandora.sf.ca.us>
Date: Thu, 12 Nov 92 21:22:58 PST
To: cypherpunks@toad.com
Subject: How to subscribe
Message-ID: <9211122121.aa04435@pandora.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


OK, I give up - what is the key I need to get on this list, 
I've tried cypherpunks-request@toad.com, and listserv@toad.com
but neither account exists. 

Can someone please add me to it.

- Mitra

P.S. If you reply, do so by email to mitra@pandora.sf.ca.us not 
to the list, as I cant receive the list yet :-)
/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Fri, 13 Nov 92 00:00:51 PST
To: cypherpunks@toad.com
Subject: Rander box and other stuff
Message-ID: <9211130757.AA27092@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


To Cypherpunks:

   I think I have a rough description of the hardware serial random
generator I want to build.    I want to call it the "Rander box" for
lack of a better name.

   It will have two serial connectors,   one an input,  and other the
output,   and connect to a modem or serial port.   Physically,  it should
have dip switch to select baud rate,   and an on-off switch.

   When switched on,   and a "cr" (or some other character) is sent to it,
random bytes will stream out continiously.   Another "cr" will stop the
byte stream.    At least this is ONE approach.   If anyone can think of
a better way,  Pse speak up.

   Next week,  I plan on consulting with another hardware guru and
formulate an initial design.    I already know what components need
to go into it,   and now I want to try and eliminate an extra UART if
I can figure out how to turn on and off the random stream via software.

   The internal code of PGP (I am told) uses an internal buffer to hold
the random bytes,  generated my environmental changes such as key strokes,
mouse movements,  or other external actions.

   Some of the Mac implementors are discussing the feasability of not
maintaining 100% portability.   I suggested that we break up the PGP
program into four parts.

  a) Incryption engine
  b) Key management engine.  
  c) GUI interface  (DOS, MacOS, UNIX, Windows,  etc) 
  d) Random number generator (machine dependent,  possibly hardware)

  Parts (a) and (b) are the "portable" parts,  and (c) and (d) are the
machine dependent parts.   Because the Mac is not multi-tasking,  we can
get around that problem by implementing a random number generator as a
driver.   Mac drivers provide for "periodic" code to be called as often
as possible,   and there are plenty of places where this driver can "look
for" environmental changes to generate random numbers using the hashing
stuff that Phil implemented.    Naturally,  the IBM-PC and UNIX versions
of software random number generation would be different.   But as far as
the Incryption and Key generators are concerned,  all they need to do,  is
to look into the random "seed" buffer.    Implementing the random number
generation as a driver also affords the possibility of having total 
independence of a hardware device,   and if one is desired,  no changes
to the code will be necessary to have one.   We just drop an appropriate
INIT into the system folder which will contain the appropriate driver.
This is the Mac way of doing things.

   One other problem I am having in participating in this group is the
extra phone expenses I will have.    I cannot get on Netcom's local lines
from here anymore because they are always busy,  and there is a lot of
other unconsiderate people that hog up all the local lines for many hours
at a time,   so mail responses to and from me,  may take days.    For
instance,  I cannot participate in any IRC chats unless I get local access,
as I am unemployed and cannot afford to call out of my area.  So please
excuse any slow responses you might get from me.

John D.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 13 Nov 92 01:20:39 PST
To: cypherpunks@toad.com
Subject: Rander box
In-Reply-To: <9211130757.AA27092@netcom2.netcom.com>
Message-ID: <9211130920.AA27066@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>   It will have two serial connectors,   one an input,  and other the
>output,   and connect to a modem or serial port.   Physically,  it should
>have dip switch to select baud rate,   and an on-off switch.

Some simplifications I might suggest:

I only think you need an output connector.  See below.

If you can power it off the RS-232 line, you won't need a power
switch.  You should be able to draw enough power off, say, the DTR
line to power a simple thing like this.

For a dedicated random number generator with low bandwidth, there's
not much reason for variable baud rate.  I'd use a fixed baud rate of,
say 1200, or even 300.  If you make it low enough you could just
kludge together a serial interface, but with the low cost of UART's,
it's probably not worth it.  You might also consider using a PIC, which
has built-in serial.

>   When switched on,   and a "cr" (or some other character) is sent to it,
>random bytes will stream out continiously.   

I'd just make the thing spew continuously.  It's not like you're
losing real, er, information if you ignore a few random bits.  This
way you don't need the added circuitry for switching on and off.

The actual use of this thing is going to require a device driver to
buffer up random bits for later use.  So all the flow control to the
higher layer happens there anyway.  And if the UART buffer overflows,
so what?

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 13 Nov 92 02:26:03 PST
To: simsong@next.cambridge.ma.us
Subject: Re: (fwd) A Silver Bullet to Limit Crypto?
Message-ID: <199211131024.AA12677@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Responding to Simsong's critique of my comparison with voter registration.

Point well taken.  Perhaps a comparison with xerox machines in the old USSR
would be more apt: the image of the copier in the guarded room with a loyal
party cadre at the door, having all comers sign a book saying what their
business is using the copier, and showing the material they'd be copying.
The KGB of course was interested in preventing "crime" such as the spreading
of anti-Soviet propaganda.  Now we would say, oh that's not crime, it's just
speech.  Exactly: enciphered text is just speech, and if an actual crime is
organised over a communications medium, the crime itself is the thing to
prosecute, not the speech.  

The parallel of state officials controlling access to communications devices
seems to be pretty straightforward to me.  But would it fly on Main
Street...?

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 13 Nov 92 08:57:54 PST
To: cypherpunks@toad.com
Subject: (fwd) A Silver Bullet to Limit Crypto?
In-Reply-To: <9211131553.AA23336@newsu.shearson.com>
Message-ID: <9211131657.AA13124@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



From: Tom.Jennings@F111.N125.Z1.FIDONET.ORG (Tom Jennings)
>I'd much rather have email users want privacy and rag about their
>compromised system. 

From: romkey@asylum.sf.ca.us (John Romkey)
>>As long as they *know* it's compromised. 

Perry:
>PGP is free software. [...]  Why put out crap when gold is available
>and cheap?

Perry, Tom _is_ using PGP.  

Please be aware of what the actual question is, rather than red-flagging
on keywords like "compromised."

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 13 Nov 92 09:21:09 PST
To: cypherpunks@toad.com
Subject: Rander box
In-Reply-To: <9211131639.AA23711@newsu.shearson.com>
Message-ID: <9211131721.AA13968@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Perry on random bit rates:
>I strongly disagree -- you really want to be able to do as high a
>bandwidth as possible. 

Cryptography is all economics.

The economics here is that John Draper is going to try to market this
thing, not play with it in the lab.  I don't know what experience you
have with electronic design, so pardon me if I condescend.  You don't
sell features that most people don't need.  You don't add parts when
only a few people are going to use the feature.  You make another
version if there is sufficient demand for higher performance.

One-time pads are expensive to make relative to other forms of
security.  Period.  No argument.  George Gleason and I had a long
conversation via email over a period of weeks about this.  He was
convinced.  If you don't believe me, ask him.

The largest need for random bits right now is for key material. If you
want to use one-time pads, fine.  They are secure, no problem.  The
random number generator we are discussing here is not suitable for
making one-time pads.  If you want one, build it.  It's not what most
people need right now.

In fact, if one-time pads are economical to use, then surely there is
a market for one-time pad systems.  Of course, if such a market does
not exist, then one-time pads don't provide economical protection for
the market as a whole.  Which do you think?

Re: continuous spewing of bits.

Perry thinks this is a bad idea because it won't work with
workstations well with respect to interrupts.  

In my previous post, I mentioned powering the device from DTR.  DTR,
for those of you not familiar with RS-232, is a device control line
which is separately assertable.  To turn the device off, toggle DTR.
Presto!  No more power, no more bits.  Simple, when you know what DTR
does.

My original point remains, though: you don't need a power switch.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: simsong@next.cambridge.ma.us (Simson L. Garfinkel)
Date: Fri, 13 Nov 92 06:24:52 PST
To: George A. Gleason <gg@well.sf.ca.us>
Subject: Re: (fwd) A Silver Bullet to Limit Crypto?
Message-ID: <9211131425.AA09897@next.cambridge.ma.us>
MIME-Version: 1.0
Content-Type: text/plain


In making public-policy arguments, analogies are dangerous.  You need to take  
time to explain them.  The opposition can use other analogies.  It's far more  
effective to argue on the facts.

With respect to encryption, the outgoing administration has argued successfully  
that encryption is the computer equivalent of a saturday night special.  That  
there is no reason to use encryption unless you don't want law enforcement to  
be able to read what you send.  They say that it is only useful against lawful  
wiretaps, because there are other protections against unlawful wiretaps (ie:  
the law).

The way to attack this is not by making an analogy to photocopiers, but by  
saying that there are many unlawful wiretaps, breakins, and thefts, and that  
most of them go unknown and unreported.  Argue that most communications that  
people have an interest in protecting are not about kidnappings but about  
business dealings.  Argue that encryption is vital for communicating with  
overseas offices, where wiretaps are even more common.  Argue that it is  
important for protecting information on your hard disk which can be stolen.

No need to argue with analogy.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 13 Nov 92 08:03:32 PST
To: strat@intercon.com
Subject: DC 2600 mtg
In-Reply-To: <9211121425.AA32211@horton.intercon.com>
Message-ID: <9211131539.AA23245@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Bob Stratton <strat@intercon.com>

>Hi all...

>I was at the latter part of the Washington 2600 meeting, feel free to ask me 
>questions if you want.

>By the way, today's article about the event was yet another example of the 
>media promoting hysteria about technologically competent people. The whole 
>article was of the "A hacker is someone who breaks into systems" model. It 
>makes me sick, and I think that the crypto community (the part NOT employed 
>by DoD) is next for this sort of misrepresentation.

Pardon, but isn't 2600 magazine a magazine by crackers for crackers?
2600 is named after frequency of the disconnect tone used in blue
boxes, isn't it? What I'm afraid of is that I will get confused with
one of them -- I'm not sure they are necessarily being misrepresented.

The tragedies come when idiots raid Steve Jackson Games and sieze
copies of "Cyberpunk" instead of shutting down the infants breaking
into TRW. Blurring the distinction between hackers and crackers is the
last thing we need.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 13 Nov 92 08:05:11 PST
To: romkey@asylum.sf.ca.us
Subject: (fwd) A Silver Bullet to Limit Crypto?
In-Reply-To: <9211122315.AA09487@asylum.sf.ca.us>
Message-ID: <9211131553.AA23336@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: romkey@asylum.sf.ca.us (John Romkey)

>   Date: Thu, 12 Nov 92 15:09:47 PDT
>   From: Tom.Jennings@F111.N125.Z1.FIDONET.ORG (Tom Jennings)

>   I'd much rather have email users want privacy and rag about their
>   compromised system. Even a relatively poor one buts some substantial
>   blocks into routine bulk monitoring of traffic...

>As long as they *know* it's compromised. Too many people out there
>think the Internet, for instance, is secure already. They don't
>realize how easily one can spy on their email, or find out if they're
>subscribed to a mailing list.

I don't see what the point of putting out mediocre things is at all,
given that good things exist. PGP is free software. You need a good
RSA implementation? There is one out there already. Why put out crap
when gold is available and cheap?

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Fri, 13 Nov 92 11:04:31 PST
To: cypherpunks@toad.com
Subject: Re: Rander box and other stuff
In-Reply-To: <9211130757.AA27092@netcom2.netcom.com>
Message-ID: <9211131904.AA29178@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


>    Some of the Mac implementors are discussing the feasability of not
> maintaining 100% portability.

If portability was a problem, the Mac would certainly be an answer.

Howabout actually trying to be Real Programmers and writing Real Software,
like the folks who did all the work that you are now benefiting from?
Instead of writing dead-end software that will only live on one platform?
I know it isn't the Macintosh Way, but you might learn something.

The last thing PGP needs is an installed base of Mac users who are
always stuck three revs back because they forked off their own wierd
version and couldn't upgrade when the rest of us do.

	John Gilmore




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 13 Nov 92 08:47:05 PST
To: crunch@netcom.com
Subject: Rander box and other stuff
In-Reply-To: <9211130757.AA27092@netcom2.netcom.com>
Message-ID: <9211131631.AA23673@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: crunch@netcom.com (John Draper)

>   I think I have a rough description of the hardware serial random
>generator I want to build.    I want to call it the "Rander box" for
>lack of a better name.

>   It will have two serial connectors,   one an input,  and other the
>output,   and connect to a modem or serial port.   Physically,  it should
>have dip switch to select baud rate,   and an on-off switch.

>   When switched on,   and a "cr" (or some other character) is sent to it,
>random bytes will stream out continiously.   Another "cr" will stop the
>byte stream.    At least this is ONE approach.   If anyone can think of
>a better way,  Pse speak up.

Why two serial connectors? RS232 is bidirectional, so you could send
control signals down the same pipe the output comes off of. Also, why
bother decoding the CRs? Seems like overkill. You could just have
CTS/RTS or other lines on the connector control whether bits are
clocked out or not. 

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Fri, 13 Nov 92 11:34:22 PST
To: cypherpunks@toad.com
Subject: Anonymous return addresses
Message-ID: <9211131935.AA24489@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


Here is an example of how to use the cryptographic remailer at
<hal@alumni.caltech.edu> to implement an anonymous return address.
Note: this material is a little complicated, but if you will take it a
step at a time you will see that there's not really that much to it.


Suppose I want to receive mail at my address of 74076.1041@compuserve.com,
but I don't want that address to be known.

First, I create a file with the following contents.  Call it t1:


---------------------- cut here -----------------------
::
Request-Remailing-To: 74076.1041@compuserve.com

---------------------- cut here -----------------------

This is the same as what you would normally put at the front of a
message to use the remailer.  Note that the last line of the file is
blank.

Now, I encrypt that file, using PGP, with the public key of the
remailer (the key is at the end of this message).  I use the command,
"pgp -ea t1 alumni".  I say "alumni" as a shorthand for the address of
the remailer on the keyring.  This creates a file, t1.asc, which looks
like:

---------------------- cut here -----------------------
-----BEGIN PGP MESSAGE-----
Version: 2.01

hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu
jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c
E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c
4RoHslyk51suvGokhod0
=XSHb
-----END PGP MESSAGE-----

---------------------- cut here -----------------------

Now, I edit the file by adding lines saying "::", and "Encrypted: PGP",
and a blank line, to the beginning (and I delete the blank line at the
end of the file), giving:

---------------------- cut here -----------------------
::
Encrypted: PGP

-----BEGIN PGP MESSAGE-----
Version: 2.01

hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu
jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c
E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c
4RoHslyk51suvGokhod0
=XSHb
-----END PGP MESSAGE-----
---------------------- cut here -----------------------


The content of this file is my anonymous return address.

To use it, I make my posting, anonymously, and I say something like:

"Anonymous return address: mail to hal@alumni.caltech.edu, with your
(possibly encrypted) message preceded by:"

and I put in the contents of my anonymous return address file, above.

So, to use this anonymous return address, suppose someone wants to
send me this message:

---------------------- cut here -----------------------
Hello, I am responding to your anonymous post on cypherpunks.
I would like to know more about your anonymous habits.
Please post some more.
---------------------- cut here -----------------------

All they need to do is to put the anonymous return address at the
beginning, giving:

---------------------- cut here -----------------------
::
Encrypted: PGP

-----BEGIN PGP MESSAGE-----
Version: 2.01

hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu
jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c
E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c
4RoHslyk51suvGokhod0
=XSHb
-----END PGP MESSAGE-----
Hello, I am responding to your anonymous post on cypherpunks.
I would like to know more about your anonymous habits.
Please post some more.
---------------------- cut here -----------------------

They would then send this to hal@alumni.caltech.edu.  The remailer
would decrypt the PGP block, finding the "Request-Remailing-To" line,
and then send it on to me.

If I had posted a PGP public key along with my anonymous return
address, they could have encrypted their message text as well, and put
the A.R.A. in front of it.  The resulting message would have looked
something like:

---------------------- cut here -----------------------
::
Encrypted: PGP

-----BEGIN PGP MESSAGE-----
Version: 2.01

hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu
jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c
E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c
4RoHslyk51suvGokhod0
=XSHb
-----END PGP MESSAGE-----
-----BEGIN PGP MESSAGE-----
Version: 2.01

hIwCqBMDr1ghTDcBA/sGAyloGGHX/CBNRFOkov8RGNxNw/HqehwZ3yT5r0n45qAt
AKmETej9GyJVFLZ5Oom7cqFN6+ARaZpp4LFqaxGF7phxC6l9HEPh2zI7w2G1/Df6
pMIwJJ7G+0vk7qBKoctmanNkYVTIb/bKAxJAbK6mUfcXPdRjyUaT/vf2X9RocKYA
AAB/sjDjuW2cSN7o3HOKvQ4s+CyqshOGWe7xLRIfSBVyL2PXFOJKx7QMVdRyzDwC
HO62PhXswqTlgxqIod0EXDzfEA8kI4Oz2gp45AMy8ElT1nV1jEKjCGC6HWGDU/P5
ZCTPgzOgmLetDNi5Yf8cPDMTHQ3Dcl7vDyNhpMD4+fdFog==
=8FPE
-----END PGP MESSAGE-----
---------------------- cut here -----------------------

The first PGP message is my anonymous return address, and the 2nd
PGP message (which the remailer won't try to decrypt) is the encrypted
message for me.

If more people will implement cryptographic remailers, you will be
able to create more secure ARA's which are "nested" so that they go
through two or more remailers, and no one remailer will see the
correspondence between your ARA and your real address.

How might you use an ARA?  You could create a pseudonym, and a public
key corresponding to it.  You could post anonymously, using our
current remailers, to this list or another list.  You could sign your
messages using the public key of your pseudonym, so no one else could
pretend to be you.  And you could put an ARA into your messages so
people could reply to you.  They could reply anonymously if they
wanted to, and could supply you with an ARA of their own.  People
could communicate freely under their online net identities, with
cryptographic protection of their True Names, a la Vernor Vinge.

Hal

P.S. Here again is the public key of the remailer at
<hal@alumni.caltech.edu>.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.01

mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi
T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2
aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg==
=K00H
-----END PGP PUBLIC KEY BLOCK-----




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 13 Nov 92 08:47:10 PST
To: hughes@soda.berkeley.edu
Subject: Rander box
In-Reply-To: <9211130920.AA27066@soda.berkeley.edu>
Message-ID: <9211131639.AA23711@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Eric Hughes <hughes@soda.berkeley.edu>

>Some simplifications I might suggest:

>For a dedicated random number generator with low bandwidth, there's
>not much reason for variable baud rate.  I'd use a fixed baud rate of,
>say 1200, or even 300.

I strongly disagree -- you really want to be able to do as high a
bandwidth as possible. You might think we don't need one time pads
ever anymore, but they are still the one and only provably absolutely
secure method out there -- thus, sources of large numbers of random
bits are going to be of use.

>>   When switched on,   and a "cr" (or some other character) is sent to it,
>>random bytes will stream out continiously.   

>I'd just make the thing spew continuously.  It's not like you're
>losing real, er, information if you ignore a few random bits.  This
>way you don't need the added circuitry for switching on and off.

Bad idea. If I hooked it up to my workstation, I'd end up spending
lots of CPU on the thing and possibly get nasty problems with buffers
filling. Not everything on earth is a PC that will ignore the
interrupts if the port isn't in use, you know.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 13 Nov 92 08:47:19 PST
To: avalon@coombs.anu.edu.au
Subject: Datalink encryption
In-Reply-To: <9211131022.AA20601@coombs.anu.edu.au>
Message-ID: <9211131640.AA23728@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: avalon@coombs.anu.edu.au (Darren Reed)

>Hi, I've started playing around with doing encryption with telnet/telnetd
>again (I'm cheating and using the rsa/prime number code from pgp-2.0)
>and I'm stuck on what to use as the encryption for the actual flow of data.
>(hmm...if it works for telnet/telnetd, it can probably be made to work for
> the other r-daemons too :-)

>The idea is telnet and telnetd each choose an rsa pub & sec key, then use
>rsa to encode a key for the encryption scheme which both ends send and
>then use that for the base of the link encryption.

Use IDEA; its sitting right in the PGP code.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bob Stratton <strat@intercon.com>
Date: Fri, 13 Nov 92 09:14:22 PST
To: pmetzger@shearson.com
Subject: Re: DC 2600 mtg
Message-ID: <9211131211.AA10662@horton.intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


> Date: Fri, 13 Nov 92 10:39:23 EST 
> From: pmetzger@shearson.com (Perry E. Metzger) 
> In-Reply-To: Bob Stratton's message of Thu, 12 Nov 1992 14:25:32 -0500 <
> 9211121425.AA32211@horton.intercon.com> Subject: DC 2600 mtg 
> 
> Pardon, but isn't 2600 magazine a magazine by crackers for crackers? 
> 2600 is named after frequency of the disconnect tone used in blue 
> boxes, isn't it? What I'm afraid of is that I will get confused with one 
> of them -- I'm not sure they are necessarily being misrepresented. 

In the case of the recent Washington Post article, I know for a fact that 
they're being misrepresented. I am one of the original attendees of that 
gathering, and I've been a professional in the computer industry for the past 
9 years, not some rodent cracker downloading /etc/passwd files.

Most of the people regularly attending that gathering are not involved in 
illicit acticity, but rather are computer and radio hobbyists, and in many 
cases are employed in those fields. I can personally attest to the fact that 
most of the discussions involve new hardware (announcements and purchases), 
and people's social lives.

I'll grant you that 2600 frequently publishes items from miscreants, but the 
publisher's consistent goal has been to raise public awareness of the risks 
of various technologies, and their social side-effects. Unfortunately, the 
media environment in the country seems more oriented to hysteria and glossing 
over facts.


> The tragedies come when idiots raid Steve Jackson Games and sieze 
> copies of "Cyberpunk" instead of shutting down the infants breaking into 
> TRW. Blurring the distinction between hackers and crackers is the last 
> thing we need. 

That's my point exactly - the media has all but abolished the distinction. 
They'd rather incite fear of the technically knowledgeable than educate the 
populace and the legislatures. The upshot of this are things like the "all 
hackers break into computers" definitions we frequently read, as well as the 
blatant misrepresentations on the part of cellular service providers that 
"your calls are private because it's illegal to listen to them". The papers 
and TV stations don't want to hear the fact that I can take an old TV set and 
listen to cellular phone calls without modifying it.

I spend a lot of time with younger aspiring hackers in the hopes that I can 
help them establish productive goals, especially as regards careers. I do 
this for three reasons: 

1) It's more personally satisfying to be paid for a job, than to have to look 
over your shoulder for law enforcement types. 

2) The world's a little bit safer for every cracker who gets steered into a 
productive career.

3) My personal experience is that many of the college graduates with CS 
degrees these days are code grinders with no understanding or enthusiasm for 
an aesthetic engineering solution. I'd much rather see people who love what 
they do designing the things I use every day.

I don't want to get too far afield of the topic of this list, so I'll stop 
here, but I really do believe, based on the precedents with firearms, radio 
receivers (scanning and paging), and recent law enforcement proposals, that 
cryptographic technology will be the next example vilified in the press of 
"things only evil people use".

Bob Stratton     Engineer, InterCon Systems Corp.     strat@intercon.com
+1 703 709 5525 (W)






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wcs@anchor.ho.att.com (Bill Stewart)
Date: Fri, 13 Nov 92 09:18:32 PST
To: crunch@netcom.com
Subject: Re: Rander box and other stuff
Message-ID: <9211131719.AA05276@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text


John Draper asked for comments on a proposed interface to the Rander box.
I would recommend using different characters to start and stop the
transmission; if you use one character for both it's easy to get out of sync.
^S and ^Q are traditional, of course, and hardware flow control is another
option (Perry's suggestion).  Of course, not everybody's machine handles
hardware flow control adequately.  If you've got a dip switch annyway,
you may want to use one switch to choose hardware or ^S/^Q.

			Bill 



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: anthrax@cow.com
Date: Fri, 13 Nov 92 09:57:45 PST
To: cypherpunks@toad.com
Subject: Hackers, Crackers
Message-ID: <9211131757.AA05188@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


Let's cut out this elitist "crackers" crap altogether.  
It's just a little bit too PlaySkool, a little bit too 
"_I'm_ not a third grader!  I'm a _fourth grader_!"  The people
who put so much energy into advertising how they're different
tend not to know what the fuck they're talking about, in 
my experience.

>>
Pardon, but isn't 2600 magazine a magazine by crackers for crackers?
<<
 
Beep.  Sorry.  Thank you for playing.
 
>>
2600 is named after frequency of the disconnect tone used in blue
boxes, isn't it?
<<
 
2600 is named after the frequency of the disconnect signal used in
the telephone system for several decades.  But so what?
 
Doesn't PGP violate patent laws (or surely come pretty close)?  Why
would you want to be associated with PGP and its use, then?
 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Fri, 13 Nov 92 13:13:30 PST
To: cypherpunks@toad.com
Subject: Rander box
Message-ID: <9211132109.AA27735@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


>>I'd just make the thing spew continuously.  It's not like you're
>>losing real, er, information if you ignore a few random bits.  This
>>way you don't need the added circuitry for switching on and off.

>Bad idea. If I hooked it up to my workstation, I'd end up spending
>lots of CPU on the thing and possibly get nasty problems with buffers
>filling. Not everything on earth is a PC that will ignore the
>interrupts if the port isn't in use, you know.

I agree,  dealing with continious data streams might be problematic,
but it was mentioned that we could use CTS/RTS or other lines on the 
connector to turn on and off the stream.    Any comments on doing it
this way?





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Fri, 13 Nov 92 13:26:53 PST
To: cypherpunks@toad.com
Subject: Rander
Message-ID: <9211132123.AA29207@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Eric says:

>In my previous post, I mentioned powering the device from DTR.  DTR,
>for those of you not familiar with RS-232, is a device control line
>which is separately assertable.  To turn the device off, toggle DTR.
>Presto!  No more power, no more bits.  Simple, when you know what DTR
>does.

So far,  I think this is the best idea,  and after checking out my
methodology and initial circuit design,  I see no reason why I cannot
go as high as 9600 baud.   Even the more inexpensive AD converters can
achieve that speed when we only want to use 8 bits.    I am toying 
around the idea for using an 8 bit AD converter,   then its just a
matter of clocking them out a UART.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Fri, 13 Nov 92 13:31:29 PST
To: cypherpunks@toad.com
Subject: PGP portability
Message-ID: <9211132127.AA29554@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


John Gilmore writes:

>The last thing PGP needs is an installed base of Mac users who are
>always stuck three revs back because they forked off their own wierd
>version and couldn't upgrade when the rest of us do.

This was why I proposed the internal "engine" concept where I keep the
machine independent code intact and the GUI seperate.    At the moment,
I can't think of a better idea.    So perhaps you can give us some
suggestions towards a solution to the problem,  John!




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dmandl@shearson.com (David Mandl)
Date: Fri, 13 Nov 92 11:35:30 PST
To: pmetzger@shearson.com
Subject: Re: DC 2600 mtg
Message-ID: <9211131905.AA00246@tardis.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


> Perry Metzger writes: 

> Pardon, but isn't 2600 magazine a magazine by crackers for crackers?

No.  It's called "The Hacker's Quarterly" and never claims to be anything
else.  Eric Corley (editor/publisher) is completely above-ground.  He
even does a computer show on WBAI here in New York, though I haven't heard
it.  In fact, he was on MY radio show (WFMU) a few years ago talking
about hackers.  I was initially surprised that he was willing to use
his real name on the show; I ended up being almost disappointed by 
how "apolitical" he seemed.  2600 prints plenty of articles by flamboyant
young pranksters on how to break into this or that system, but rather
than an editorial line or policy, this is more a result of 2600's view
that all this information should be available and uncensored.  These are
the kinds of guys who uncover holes in multinationals' computer security
and TELL THEM about it.  (BTW, I'm not involved with the magazine in any
way; in fact, I find most of its articles kinda uninspiring or mundane.)

   --Dave.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: jordan@imsi.com (Jordan Hayes)
Date: Fri, 13 Nov 92 11:58:01 PST
To: cypherpunks@toad.com
Subject: Re:  Hackers, Crackers
Message-ID: <9211131918.AA17661@IMSI.COM>
MIME-Version: 1.0
Content-Type: text/plain


	From anthrax@cow.com Fri Nov 13 14:03:27 1992

	Doesn't PGP violate patent laws (or surely come pretty close)?
	Why would you want to be associated with PGP and its use,
	then?

Are you saying that contributing to this mailing list (let alone
*subscribing* to it) necessarily implies that one is using the PGP
code?

If so, take me off.

/jordan




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: S.E. Brown <shawnb@ecst.csuchico.edu>
Date: Fri, 13 Nov 92 16:07:22 PST
To: cypherpunks@toad.com
Subject: The legality of PGP
Message-ID: <9211140007.AA19365@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Well,

I've been reading a lot of speculation and outright disinformation about
the legality of PGP.  Does anyone have any informed information about the
actual legal status us sing and disseminating the program?

Gratis

My SuperIllegal Key :

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAirSjlcAAAED/ijVaTjlU62mQdXwxj+bEO3wqdMKkZlRNt1rSi8VOSkeQ0G7
7KbBeINoVCTIi12ax74q7ANhKCga+ZkBxAVTnfSBQZXfFh/5XMxzzqk7NT2fKKlZ
/Hrf4cDd8VYgSl6WPhyVO+EpvyZn5HezGLBbryGpCcloSmjBcwd2g1pYVIhjAAUR
tCxTLkUuIEJyb3duIDxzaGF3bmJAY3NjaWhwLmVjc3QuY3N1Y2hpY28uZWR1Pg==
=Wrv7
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: schwarte@CS.ColoState.EDU (eric schwartz)
Date: Fri, 13 Nov 92 16:47:32 PST
To: cypherpunks@toad.com
Subject: Re: Take You Off
Message-ID: <9211140047.AA02325@beethoven>
MIME-Version: 1.0
Content-Type: text/plain


> 
> >>
> Are you saying that contributing to this mailing list (let alone
> *subscribing* to it) necessarily implies that one is using the PGP
> code?
> 
> 
> If so, take me off.
> <<
> 
> As a counter to that, would you or Perry necessarily imply that
> subscribing to a "KrAcKeR" magazine makes you an evil
> "KrAcKeR"?
>  
> Anyway, if you can figure out the unix commands to navigate through
> your mail-box, then you should have just enough intelligence
> not to have jumped to any short-sided conclusions like the one
> you proposed above.
>  
> Then again, I could be wrong.
> 

Then again, you could be missing his (albeit subtly) sarcastic point, which is
exactly what you just said.

Sheesh.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Fri, 13 Nov 92 19:23:48 PST
To: cypherpunks@toad.com
Subject: re: (fwd) A Silver Bullet to Limit Crypto?
Message-ID: <3613.2B045BBE@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: pmetzger@shearson.com (Perry E. Metzger)

 U> I don't see what the point of putting out mediocre things 
 U> is at all, given that good things exist. PGP is free 
 U> software. You need a good RSA implementation? There is one 
 U> out there already. Why put out crap when gold is available 
 U> and cheap? 

I don't think anyone has a desire to put bad things out there. My
comments were assuming the real-life context of FidoNet, where we
have a need to get people thinking about privacy, security, etc, and
our relationships and responsibilities to each other.

We *are* using PGP, which seems to be good software. Any "mediocrity"
or inherent flaws I was referring to were in key systems, and
suchlike. The social environment in FidoNet is completely different
from here. There will never be any directed training or committees to
define what a "proper" way to handle keys is, and even if there was,
the newbie sysop coming online in East Overshoe Alaska wouldn't even
hear about it, and would install what s/he finds available on the net.

All of our social/technical systems assume this chaotic environment.
It makes for some ahem interesting problems, but the robustness and
growth and innovation are pretty hot.

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Fri, 13 Nov 92 19:23:25 PST
To: cypherpunks@toad.com
Subject: re: Rander box and other stuff
Message-ID: <3612.2B045BBD@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: crunch@netcom.com (John Draper)

 U>    I think I have a rough description of the hardware 
 U> serial random generator I want to build.    I want to call 
 U> it the "Rander box" for lack of a better name. 

Using serial ports is probably not a good idea on PC clones. The IBM
hardware design limits a machine to two ports comfortably, four
practical maximum. Any machine that uses telecomm. (BBSs, etc) will
have to consume the serial hardware, and will interfere with whatever
you have to do.

A good choice would be a parallel port, ie. a printer port. The IBM
design allows 4 or more easily, and rarely do you see a pclone with
more than two printers attached. If there isn't a spare port
available, Fry's sells printer adapters for $19.95. Late-model printer
adapters are 8 bit in and out, and are capable of Ethernet speeds.
The parallel port uses standard busy/done and TTL levels.

(For a "universal" serial version, you could internally have the 8 bit
busy/done interface drive a UART. I bet simply fixing the data rate
to 9600 baud would work.)

 U>    When switched on,   and a "cr" (or some other 
 U> character) is sent to it, random bytes will stream out 
 U> continiously.   Another "cr" will stop the byte stream.    
 U> At least this is ONE approach.   If anyone can think of a 
 U> better way,  Pse speak up. 

I was about to say "prolly not necessary", but others make valid
points... XON/XOFF, DTR, etc are all workable... DTR is compat
w/serial and parallel too.

On a pclone, producing bits continuously is easier. When not in use,
the driver will dump bits onto the floor. Fancy (software) drivers
could spool the bits into a nice big pile ("every bit is sacred...").
A simple driver could simply have say 10,000 bits, and continuously
overwrite the oldest (wrap around the buffer...)

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: anthrax@cow.com
Date: Fri, 13 Nov 92 15:41:16 PST
To: jordan@imsi.com
Subject: re: Take you off
Message-ID: <9211132341.AA06610@atdt.org>
MIME-Version: 1.0
Content-Type: text/plain


>>
Are you saying that contributing to this mailing list (let alone
*subscribing* to it) necessarily implies that one is using the PGP
code?


If so, take me off.
<<

As a counter to that, would you or Perry necessarily imply that
subscribing to a "KrAcKeR" magazine makes you an evil
"KrAcKeR"?
 
Anyway, if you can figure out the unix commands to navigate through
your mail-box, then you should have just enough intelligence
not to have jumped to any short-sided conclusions like the one
you proposed above.
 
Then again, I could be wrong.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: S.E. Brown <shawnb@ecst.csuchico.edu>
Date: Fri, 13 Nov 92 18:44:10 PST
To: cypherpunks@toad.com
Subject: PGP 2.01 2.02
Message-ID: <9211140244.AA22290@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Where can the latest revisions of PGP be found?
Tried the sci.crypt archive site, but the just had 2.0.
Can anyone help?

BTW, here's my key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAirSjlcAAAED/ijVaTjlU62mQdXwxj+bEO3wqdMKkZlRNt1rSi8VOSkeQ0G7
7KbBeINoVCTIi12ax74q7ANhKCga+ZkBxAVTnfSBQZXfFh/5XMxzzqk7NT2fKKlZ
/Hrf4cDd8VYgSl6WPhyVO+EpvyZn5HezGLBbryGpCcloSmjBcwd2g1pYVIhjAAUR
tCxTLkUuIEJyb3duIDxzaGF3bmJAY3NjaWhwLmVjc3QuY3N1Y2hpY28uZWR1Pg==
=Wrv7
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
Date: Fri, 13 Nov 92 19:23:56 PST
To: cypherpunks@toad.com
Subject: 1/3 Cryptography bibliography
Message-ID: <3615.2B0467B1@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



    * Forwarded by Rich Veraa
      To:  All                        Message #:  365
    From:  Ed Beroset                 Submitted:  10 Nov 92  20:34:38
 Subject:  1/3 cryptographic bibliog     Status:  Public
Received:  ** New Message Read! **        Group:  80XXX (17)

I'm sorry it took me a little longer than I had anticipated to put together
this list, but I think you'll find it worth while.  This is a list of books
which deal with various aspects of cryptography (including DES, RSA, and many
other schemes and topics.)  They're organized roughly in reverse chronological
order, with newer texts toward the top of the list.

TITLE : Cryptography : a new dimension in computer data security : a guide
        for the design and implementation of secure systems /
AUTHOR: Meyer, Carl H.
IMPR  : New York : Wiley, 1982.

TITLE : Traffic analysis and the Zendian problem : an exercise in
        communications intelligence operations /
AUTHOR: Callimahos, Lambros D.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1989.

TITLE : Military communications : a test for technology /
AUTHOR: Bergen, John D., 1942-.
IMPR  : Washington, D.C. : Center of Military History, U.S. Army : For sale
        by the Supt. of Docs., U.S. G.P.O., 1986.

TITLE : Principles of secure communication systems /
AUTHOR: Torrieri, Don J.
IMPR  : Dedham, MA : Artech House, c1985.

TITLE : Contemporary cryptology : the science of information integrity /
IMPR  : Piscataway, NJ : IEEE Press, c1992.

TITLE : Public-key cryptography : state of the art and future directions :
        E.I.S.S. workshop, Oberwolfach, Germany, July 3-6 1991 : final report
       / IMPR  : Berlin ; New York : Springer-Verlag, 1992.

TITLE : Advances in cryptology--EUROCRYPT '91 : Workshop on the Theory and
        Application of Cryptographic Techniques, Brighton, UK, April 8-11,
        1991 : proceedings /
AUTHOR: EUROCRYPT '91 (1991 : Brighton, England)
IMPR  : Berlin ; New York : Springer-Verlag, c1991.

TITLE : United States cryptographic patents, 1861-1989 /
ED    : [2nd ed.]
AUTHOR: Levine, Jack, 1907-.
IMPR  : Terre Haute, Ind. : Cryptologia, 1991.

TITLE : Geometries, codes and cryptography /
IMPR  : Wien ; New York : Springer-Verlag, c1990.

TITLE : Number theory and cryptography /
IMPR  : Cambridge ; New York : Cambridge University Press, 1990.

TITLE : Cryptography : an introduction to computer security /
AUTHOR: Seberry, Jennifer, 1944-.
IMPR  : New York : Prentice-Hall, c1989.

TITLE : Codes and cryptography /
AUTHOR: Welsh, D. J. A.
IMPR  : Oxford [Oxfordshire] : Clarendon Press ; New York : Oxford University
        Press, 1988.

TITLE : Crypto users' handbook : a guide for implementors of cryptographic
        protection in computer systems /
IMPR  : Amsterdam [The Netherlands] ; New York : North-Holland ; New York,
        N.Y., U.S.A. : Sole distributors for the U.S.A. and Canada, Elsevier
        Science Pub. Co., 1988.

TITLE : An introduction to cryptology /
AUTHOR: Tilborg, Henk C. A. van, 1947-.
IMPR  : Boston : Kluwer Academic Publishers, c1987.

TITLE : Modern cryptology : a tutorial /
AUTHOR: Brassard, Gilles, 1955-.
IMPR  : New York : Springer-Verlag, c1988.

TITLE : A course in number theory and cryptography /
AUTHOR: Koblitz, Neal, 1948-.
IMPR  : New York : Springer-Verlag, c1987.

TITLE : Cryptology yesterday, today, and tomorrow /
IMPR  : Norwood, MA : Artech House, c1987.

TITLE : Mathematical cryptology for computer scientists and mathematicians /
AUTHOR: Patterson, Wayne, 1945-.
IMPR  : Totowa, N.J. : Rowman & Littlefield, 1987.

TITLE : Analysis and design of stream ciphers /
AUTHOR: Rueppel, Rainer A., 1955-.
IMPR  : Berlin ; New York : Springer-Verlag, c1986.

TITLE : Primality and cryptography /
AUTHOR: Kranakis, Evangelos.
IMPR  : Stuttgart : Teubner ; Chichester [Sussex] ; New York : Wiley, c1986.

-+--- continued next message -----


--- XAP 1.02+
 * Origin: the birds round about are against her; (1:135/907)
--  
tom jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG

rom fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings@kumr.lns.com  Fri Nov 13 19:23:59 1992
Return-Path: <fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings@kumr.lns.com>
Received: from kumr.lns.com by toad.com id AA23114; Fri, 13 Nov 92 19:23:59 PST
Received: by kumr.lns.com (/\==/\ Smail3.1.25.1 #25.3)
	id <m0mqDhq-0002c1C@kumr.lns.com>; Fri, 13 Nov 92 18:57 PST
Received: by fidogate.FIDONET.ORG (mailout1.26); Fri, 13 Nov 92 18:42:59 PDT
Date: Fri, 13 Nov 92 18:56:32 PDT
Message-Id: <3616.2B0467B3@fidogate.FIDONET.ORG>
From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
Subject: 2/3 Cryptography bibliography
To: cypherpunks@toad.com
X-Mailer: mailout v1.26 released


    * Forwarded by Rich Veraa
      To:  All                        Message #:  366
    From:  Ed Beroset                 Submitted:  10 Nov 92  20:34:38
 Subject:  2/3 cryptographic bibliog     Status:  Public
Received:  ** New Message Read! **        Group:  80XXX (17)

RE: 2/3 cryptographic bibliography

-+--- continued from previous message -----

TITLE : Two issues in public-key cryptography : RSA bit security and a new
        knapsack type system /
AUTHOR: Chor, Ben-Zion.
IMPR  : Cambridge, Mass. : MIT Press, c1986.

TITLE : Kryptologie /
AUTHOR: Horster, Patrick.
IMPR  : Mannheim : Bibliographisches Institut, c1985.
LANG  : German

TITLE : Machine cryptography and modern cryptanalysis /
AUTHOR: Deavours, Cipher A.
IMPR  : Dedham, MA : Artech House, c1985.

TITLE : Cryptanalysis of shift-register generated stream cipher systems /
AUTHOR: Barker, Wayne G.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1984.

TITLE : Applied cryptology, cryptographic protocols, and computer security
        models.
IMPR  : Providence, R.I. : American Mathematical Society, c1983.

TITLE : Secure digital communications /
IMPR  : Wien ; New York : Springer-Verlag, c1983.

TITLE : Cipher systems : the protection of communications /
AUTHOR: Beker, Henry.
IMPR  : New York : Wiley, c1982.

TITLE : Codes, ciphers, and computers : an introduction to information
        security /
AUTHOR: Bosworth, Bruce.
IMPR  : Rochelle Park, N.J. : Hayden Book Co., c1982.

TITLE : Cryptography and data security /
AUTHOR: Denning, Dorothy Elizabeth Robling, 1945-.
IMPR  : Reading, Mass. : Addison-Wesley, c1982.

TITLE : Secure communications and asymmetric cryptosystems /
IMPR  : Boulder, Colo. : Published by Westview Press for the American
        Association for the Advancement of Science, 1982.

TITLE : Cryptography, a primer /
AUTHOR: Konheim, Alan G., 1934-.
IMPR  : New York : Wiley, c1981.

TITLE : The origin and development of the National Security Agency /
AUTHOR: Brownell, George A.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, 1981.

UNI-TI: Traite de cryptographie. English.
TITLE : Treatise on cryptography /
AUTHOR: Langie, Andre, 1871-.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1981.

TITLE : Cryptanalysis of an enciphered code problem : where an "additive"
        method of encipherment has been used /
AUTHOR: Barker, Wayne G.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1979.

UNI-TI: Chifferbyraernas insatser i varldskriget till lands. English.
TITLE : The contribution of the cryptographic bureaus in the World War /
AUTHOR: Gylden, Yves.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1978.

TITLE : The protection of data by crytography /
AUTHOR: Davies, (Donald Watts)
IMPR  : Middlesex : National Physical Laboratory, 1978.

TITLE : Cryptanalysis of the Hagelin cryptograph /
AUTHOR: Barker, Wayne G.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1977.

UNI-TI: Manuale di crittografia. Italian.
TITLE : Manual of cryptography /
AUTHOR: Sacco, Luigi.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1977.

TITLE : Pattern-word list /
AUTHOR: Lynch, Frederick D.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1977-.

-+--- continued next message -----


--- XAP 1.02+
 * Origin: If at first you don't succeed, try, try a bird. (1:135/907)
--  
tom jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
Date: Fri, 13 Nov 92 19:24:04 PST
To: cypherpunks@toad.com
Subject: 3/3 Cryptography bibliography
Message-ID: <3617.2B0467B4@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



    * Forwarded by Rich Veraa
      To:  All                        Message #:  367
    From:  Ed Beroset                 Submitted:  10 Nov 92  20:41:08
 Subject:  3/3 cryptographic bibliog     Status:  Public
Received:  ** New Message Read! **        Group:  80XXX (17)

-+--- continued from previous message -----

TITLE : Advanced military cryptography /
AUTHOR: Friedman, William Frederick, 1891-.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1976.

TITLE : Elementary military cryptography /
AUTHOR: Friedman, William Frederick, 1891-.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1976.

TITLE : Elements of cryptanalysis /
AUTHOR: Friedman, William Frederick, 1891-.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1976.

TITLE : Statistical methods in cryptanalysis /
ED    : [Rev. ed.]
AUTHOR: Kullback, Solomon.
IMPR  : Laguna Hills, Calif. : Aegean Park Press, c1976.

TITLE : Mathematical recreations & essays /
ED    : 12th ed.
AUTHOR: Ball, Walter William Rouse, 1850-1925.
IMPR  : Toronto ; Buffalo : University of Toronto Press, [1974]

TITLE : Elementary cryptanalysis; a mathematical approach.
AUTHOR: Sinkov, Abraham, 1907-.
IMPR  : [New York] Random House [c1968]

-+--- end of listing -----

I think that you'll find there's a lot more useful information out
there, just waiting for you at your public library.  The U.S.
Government can also be a useful source of information, as are trade
and technical journals and hobbyist magazines.  

-> Ed <-

--- XAP 1.02+
 * Origin: two birds alive and clean, (1:135/907)
--  
tom jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 13 Nov 92 18:59:39 PST
To: shawnb@ecst.csuchico.edu
Subject: PGP 2.01 2.02
In-Reply-To: <9211140244.AA22290@toad.com>
Message-ID: <9211140259.AA12754@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



As of now, PGP 2.0 is the current version.  A newer one will be out
shortly (it's being tested).  The list will certainly be the first to
know.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: avalon@coombs.anu.edu.au (Darren Reed)
Date: Fri, 13 Nov 92 02:22:34 PST
To: cypherpunks@toad.com
Subject: Datalink encryption
Message-ID: <9211131022.AA20601@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain



Hi, I've started playing around with doing encryption with telnet/telnetd
again (I'm cheating and using the rsa/prime number code from pgp-2.0)
and I'm stuck on what to use as the encryption for the actual flow of data.
(hmm...if it works for telnet/telnetd, it can probably be made to work for
 the other r-daemons too :-)

The idea is telnet and telnetd each choose an rsa pub & sec key, then use
rsa to encode a key for the encryption scheme which both ends send and
then use that for the base of the link encryption.

Whatever I use for encryption of the session data has to work quickly
and efficiently and I've got little idea about what to use/how to
and would like some opinions on what would make a good choice.
Any suggestions ?  (Xor seems a possibility but straight Xor is very
easy to break).

I hope I'm not duplicating work that has already been done :)

cheers,
Darren




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Fri, 13 Nov 92 22:38:47 PST
To: Tom.Jennings@f111.n125.z1.fidonet.org (Tom Jennings)
Subject: Re: Rander box and other stuff
In-Reply-To: <3612.2B045BBD@fidogate.FIDONET.ORG>
Message-ID: <9211140637.AA25631@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



All of these designs leave us Mac users a bit out in the cold.  My powerbook
100 has one lonely little serial port and no parallel port.  Desktop macs
usually have two serial ports, and it's not easy to add more.

For us powerbook users (and also for users of other notebooks), we want
something which is internal.  It's horible to have little things dangling
off of your nice little notebook.  They inevitably get pulled out, etc.

Basically it seems to me that a good solution would be to use some type of
serial device for Unix type machines, and then work on a series of cards for
IBM clones and notebooks.  How about a random bit device on one of those
little cards that most of the newer notebooks have?  I forget the name of
the standard for that, but lots of them use it now.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: simsong@next.cambridge.ma.us (Simson L. Garfinkel)
Date: Fri, 13 Nov 92 22:24:49 PST
To: crunch@netcom.com (John Draper)
Subject: Re: Rander
Message-ID: <9211140619.AA11189@next.cambridge.ma.us>
MIME-Version: 1.0
Content-Type: text/plain


Perhaps I'm just out of the loop, but what do you intend to do with your stream  
of random numbers?  You going to send a tape to your friends under armed guard?

Just curious.

Oh, I built a hardware random number generator a few years ago for some ESP  
experiments I was doing.  I wanted to see if computer hackers had better odds  
of affecting the output of a RNG than non-hackers.  (You know, the hacker walks  
into the room and suddenly the broken piece of equipment starts working?)

Turns out they can.

-simson




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Sat, 14 Nov 92 01:23:48 PST
To: cypherpunks@toad.com
Subject: Rander
Message-ID: <9211140920.AA01475@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Tom Jennings writes:

>Using serial ports is probably not a good idea on PC clones. The IBM
>hardware design limits a machine to two ports comfortably, four
>practical maximum. Any machine that uses telecomm. (BBSs, etc) will
>have to consume the serial hardware, and will interfere with whatever
>you have to do.

>A good choice would be a parallel port, ie. a printer port. The IBM
>design allows 4 or more easily, and rarely do you see a pclone with
>more than two printers attached. If there isn't a spare port
>available, Fry's sells printer adapters for $19.95. Late-model printer
>adapters are 8 bit in and out, and are capable of Ethernet speeds.
>The parallel port uses standard busy/done and TTL levels.

I already thought of that,   but it would make it difficult to 
work on other platforms.   Tom also writes:

>A simple driver could simply have say 10,000 bits, and continuously
>overwrite the oldest (wrap around the buffer...)

This was (and probably still is) my overall intention.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sat, 14 Nov 92 04:11:21 PST
To: hughes@soda.berkeley.edu
Subject: Re:  Rander box
Message-ID: <199211141210.AA21995@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Re Eric's quote of me agreeing with him that OTPs are "expensive to make
relative to other forms of security."  A point of clarification seems in
order.

I do agree that OTPs are more expensive and less convenient to use than
PKSs.  However, I also believe that the public interest would *best* be
served by having *many* different kinds of cyphers available, including
OTPs, PKSs, and various conventional cyphers, historic cyphers with
relatively little current security value (for educational purposes) and so
on.  The main advantages of OTPs are provable absolute security and the fact
that the basic technique is so straightforward that it probably could never
be banned and put out of circulation.   The time may come when we *need*
OTPs, and we ought to have them ready beforehand, and have them in use in
appropriate situations long before any crisis comes (to gain operational
experience which could lead to improvements).  

With regard to PGP, I am not sure what the copyright status is on that one;
and if there is any doubt about it, the govt could screw a lot of people to
the wall on copyright-related charges if they so chose.  I would like it
very very much if PGP was free & clear public domain.  The last thing we
need is for the first warning of tyrrany to be a wave of hardware seizures
on the grounds of having unauthorised copies of copyrighted material.  Now I
may be off base on this point, but the key here is the idea that many
different kinds of cyphers, like many different varieties of plants and
animals, make for a robust ecosystem which can't be wiped out by one plague.

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: jordan@imsi.com (Jordan Hayes)
Date: Sat, 14 Nov 92 06:59:01 PST
To: cypherpunks@toad.com
Subject: Re: Rander box and other stuff
Message-ID: <9211141425.AA00660@IMSI.COM>
MIME-Version: 1.0
Content-Type: text/plain


Hey, I have a PowerBook too, but don't say you're limited to one serial
port.  You could use the desktop bus, and there are extenders
available.  I do agree that a parallel box wouldn't do me much good on
my Sparc.  For a while, my IPX was my "portable" computer, albeit with
monitors on both coasts.  But the box itself is quite lugable.  If I
wanted to, I could plug it in along the hallways of airports and use a
palmtop with a serial connection to read mail and up/down load ...

/jordan




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 14 Nov 92 10:55:08 PST
To: cypherpunks@toad.com
Subject: "Cryptodiversity" and Foiling the "Key Grabbers"
In-Reply-To: <199211141210.AA21995@well.sf.ca.us>
Message-ID: <9211141851.AA05846@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


George Gleason argues for having and using several types of
cryptosystems, a kind of "cryptodiversity." He writes:

> I do agree that OTPs are more expensive and less convenient to use than
> PKSs.  However, I also believe that the public interest would *best* be
> served by having *many* different kinds of cyphers available, including
> OTPs, PKSs, and various conventional cyphers, historic cyphers with
> relatively little current security value (for educational purposes) and so
> on.  The main advantages of OTPs are provable absolute security and the fact
> that the basic technique is so straightforward that it probably could never
> be banned and put out of circulation.   The time may come when we *need*
> OTPs, and we ought to have them ready beforehand, and have them in use in
> appropriate situations long before any crisis comes (to gain operational
> experience which could lead to improvements).  
..........
> on the grounds of having unauthorised copies of copyrighted material.  Now I
> may be off base on this point, but the key here is the idea that many
> different kinds of cyphers, like many different varieties of plants and
> animals, make for a robust ecosystem which can't be wiped out by one plague.

A great idea. Getting several forms of crypto out there is a good
insurance policy. The problem I see is that no system, be it OTP or
something else, is likely to get much penetration in the market. PGP
has taken off, but another system will face an uphill battle unless it
is very well-written, very easy to use, and/or fills some special
need.

Still, I want to encourage George to pursue this (somehow). I have a
CD-ROM on my Mac, but I doubt it'll be practical to burn CD-ROMs
economically (one service wants $200 for one CD-ROM, with a second one
for nominally more...and note that such a service is an obvious
security hole). 128 MB magneto-opticals may be a better bet, though
few folks have them.

In terms of programming energy, vis-a-vis a point John Gilmore made
recently about adding to the PGP effort, I'm sure enhancing PGP by
integrating it into standard mailers (yes, I'm aware of the security
holes here, too) would be even more beneficial to cryptodiversity,
just in the sense of getting the volume of encrypted traffic way up. A
good Mac version would also help, of course.

And to head off the "key grabbers," developing steganographic methods
to hide our encrypted bitstreams inside innocuous GIF files and the
like (as I have written about before) may be useful.

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 14 Nov 92 11:15:08 PST
To: cypherpunks@toad.com
Subject: Re: Rander box and other stuff
Message-ID: <9211141911.AA08123@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Eric Hollander writes:

> All of these designs leave us Mac users a bit out in the cold.  My powerbook
> 100 has one lonely little serial port and no parallel port.  Desktop macs
> usually have two serial ports, and it's not easy to add more.
> 
> For us powerbook users (and also for users of other notebooks), we want
> something which is internal.  It's horible to have little things dangling
> off of your nice little notebook.  They inevitably get pulled out, etc.

Maybe I'm being crypto-dense, but why would individual Powerbook 100
users care so much about generating the bits in the volumes that a
hardware-based RNG is designed to supply?

For filling a CD-ROM (600 MB) with good random bits, I can see the
need for a back-biased diode source (such as Tony Patti's widget), but
such filling of a CD-ROM presumes a fair amount of other stuff, like
the CD-ROM burners, etc. I can't imagine a PB 100 user, and I'm one of
them, developing OTPs on CD-ROMs on the PowerBook.

For generating PGP keys, the keyboard timing methods work quite well,
as several folks have pointed out.

Maybe for some of the dynamic key generation applications that will be
appearing in the next couple of years such a hardware RNG will be
useful (so that the bits can be generated in the absence of a human
operator, and at higher rates). But I don't see them needed
immediately, and certainly not on a PowerBook. (No insult to the
PowerBook, it's just that I can't see Eric Hughes' and Hal Finney's
remailer running on such a platform, for obvious reasons.)

Am I missing something?

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Sat, 14 Nov 92 14:02:15 PST
To: cypherpunks@toad.com
Subject: Some organizational trivia to consider
Message-ID: <9211142158.AA23080@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


   I will be "off line" for a few days now,  as I have to do some work
to help out an old friend.    I'll be back "on line" sometime late
Tuesday,  and hopefull will have formulated some organizational plan
to propose to the group.    In the meantime,   start thinking about
how we can organize "on line" meetings (Or even meetings in person)
to hammer out some type of plan.

   Someone mentioned a meeting to be taken place later,    is this
meeting for the Cypherpunks project?

   My involvement at this point will be that of an adviser,   and
perhaps pump in some ideas to the group.    As the host of the
Programmers Netsork,  I am experienced at setting up organizational
groups,    but often these groups tend to "fizzle out" as people have
other time committments,   so it's important that we try and work out
a mechanism for "passing the torch" when one person has to bow out
for some reason.    

   My recommendation is to set up an FTP site where one can download the
latest organizational plan,   people involved,   who is doing what,  etc,
and keep this info updated on a regular basis.    I don't recommend that
just ONE person do this,   it has to be done by several people in the event
one (or more) have to drop out for some reason.

   In the meantime,  just be thinking about the following:
   
a) Setting up a cypherpunks FTP site to contain organizational info,  latest
   source code,  who is doing what,   and a list of things that need to be
done.
   
b) Maintaining a SOurce code control mechanism whereby people can "check out"
   code modules and work in parallel towards a common goal.
   
c) Provide periodic updates by posting important info to the rest of Cyberspace
   via UseNet or other on-line systems.
   
   Till next Tuesday,  take care Y'all....   See U in Cypherspace next Tues
   
Cheers
John Draper
crunc@netcom.com
crunch@well.sf.ca.us




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sat, 14 Nov 92 16:27:09 PST
To: tcmay@netcom.com
Subject: Re: Rander box and other stuff
Message-ID: <199211150026.AA01440@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


I have a question regarding the ideas which have been circulating about
using CD ROMs as key storage.  How does one go about rapidly and effectively
erasing everything on a CD ROM?  The reason I ask is, in the case of OTPs
you want to cancel your key as it's used, to prevent accidental double-use
of key; and of course in any system you want to make sure that all your
crypto material can be wiped squeaky clean in the event of a barbarian
invasion.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 14 Nov 92 17:30:13 PST
To: crunch@netcom.com (John Draper)
Subject: Re: Some organizational trivia to consider
In-Reply-To: <9211142158.AA23080@netcom2.netcom.com>
Message-ID: <9211150126.AA08860@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



>    Till next Tuesday,  take care Y'all....   See U in Cypherspace next Tues
>    
> Cheers
> John Draper

"Cypherspace" is a _great_ name! Thanks, John.

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 14 Nov 92 18:22:36 PST
To: cypherpunks@toad.com
Subject: What's More Important?
Message-ID: <9211150219.AA12711@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


I try to never say on lists or newsgroups that some subject is
inappropriate, or boring, has already been beaten to death, etc.
Instead, I figure it's up to others to make this choice. I can always
ignore threads that don't interest me.

But let me confess I'm mystified as to why the subject of random
number generators (and CD-ROMs filled with them) is getting so much
attention while Hal Finney's remarkable post on his work toward a
fully-encrypted remailer (allowing digital pseudonyms) has received
no discussion whatsover!

Random number generators, in software and in hardware, pop up in
discussions on sci.crypt every couple of months or so. Every argument
made here, every basic question, etc., has already come up several
times in just past year! Furthermore, and I don't mean to sound
chiding or condescending, one-time pads are fundamentally not the way
to go. Yes, I know that I just applauded George Gleason's
cryptodiversity idea...but I see the stark contrast between the dozens
of postings on RNGs, Rander, one-time pads, and CD-ROMs and the utter
lack of postings about Hal's remailer...and I am chagrined.

Granted, Hal's system is hard to follow. This is another area where
some diagrams would help immensely, especially drawn on a blackboard.

But anonymous remailing is where cypherpunks need to be.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Keith Basil <basil@cs.odu.edu>
Date: Sat, 14 Nov 92 16:15:04 PST
To: cypherpunks@toad.com
Subject: cypherpunks mail list.
Message-ID: <9211150014.AA14236@penda.cs.odu.edu>
MIME-Version: 1.0
Content-Type: text/plain



	i'd like to be added to the list.  thanks.

	keith




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sun, 15 Nov 92 00:42:09 PST
To: tcmay@netcom.com
Subject: Re:  What's More Important?
Message-ID: <199211150841.AA06938@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


I suspect the reason why anon remailers haven't gotten their due, and OTPs
are getting so much press here, is that anon remailers are being developed
locally and the development problems for these are straightforward, whereas
good RNGs for OTPs are a sort of sticky technical issue which seems to call
for a lot of debate.  You don't see anyone debating the **software** for
OTPs now, do you...?  

And I do agree, anon remailers are absolutely vital in the overall scheme of
things.  If for no other reason, to stop or hinder traffic analysis, which
is a way more powerful form of signals intelligence than most people
realise. 

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Sun, 15 Nov 92 03:17:12 PST
To: cypherpunks@toad.com
Subject: test message
Message-ID: <9211151118.AA09055@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


This is an un-encrypted test message.  Please ignore.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: oren@apple.com
Date: Sun, 15 Nov 92 13:42:22 PST
To: cypherpunks@toad.com
Subject: Re: Apple including PKS?
Message-ID: <9211152141.AA24753@apple.com>
MIME-Version: 1.0
Content-Type: text/plain


>Re: Apple include a PKS with their Macs
>
>Well, Apple does have a site license for RSA.  Tim Oren, who's on the
>list, knows more about this than I.  I ask him to respond.
>
>Maybe Apple could license the PGP code as a system utility?
>
>Eric

Apple does have a license from RSA, which includes both site and
redistribution rights.  The intent is to make security-enhanced features
available in something called OCE (Open Collaboration Environment) which is
to be Apple's entry in the E-mail / user directory / etc.  marketplace. 
OCE is likely to be an add-on, that is, something not shipped with every
Mac, but available at extra cost.  Since I'm under NDA for the details of
OCE, I will simply quote what MacLeak says:

 According to MacWeek, Apple is using RSA software with 150-200 digit
primes for Digital Signatures. They are using "RSA's RC4 algorithm [which
will] provide
 encryption of the fly for data transmitted across an OCE (open
Collaboratioon Environment) network. Each message will be scrambled using a
unique 64-bit key.

BTW, notice that's decimal digits, not bits, in the signature length.

Apple is set up as a certifying authority, but I don't know any details of
the plans on how to certify keys.  It's a far from simple problem to work
out something that will work in the current personal computer market
structure and isn't subject to spoofing.

Re Apple licensing PGP code:  While Apple could presumably do so without
violating any laws, so long as any copyright holders in PGP granted
appropriate rights, I don't think it's very likely.  OCE is a package to be
differentiated by its user interface, and apparently MacPGP's (though I
haven't tried it myself yet) is rather crufty from the Mac point of view. 
Also, Apple traditionally wants very tight control over its source code,
and is unlikely to adopt something that arrives in such a (shall we say)
'informal' fashion from outside.

Finally, as a dose of preventive medicine, I should mention that all of the
above is my best interpretation of Apple policy and probable action, with
which I don't necessarily agree personally.  Flameage ignoring this
statement will be routed appropriately.

Tim Oren





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: oren@apple.com
Date: Sun, 15 Nov 92 13:48:38 PST
To: cypherpunks@toad.com
Subject: Re: Rander box and other stuff
Message-ID: <9211152148.AA24934@apple.com>
MIME-Version: 1.0
Content-Type: text/plain


>I have a question regarding the ideas which have been circulating about
>using CD ROMs as key storage.  How does one go about rapidly and effectively
>erasing everything on a CD ROM?  The reason I ask is, in the case of OTPs
>you want to cancel your key as it's used, to prevent accidental double-use
>of key; and of course in any system you want to make sure that all your
>crypto material can be wiped squeaky clean in the event of a barbarian
>invasion.  
>
>-gg

A lab proven method:  Take CD-ROM.  Place in standard kitchen microwave. 
Set on high power cook for 5 seconds.  Press start.  Watch the action. 
Hang resulting artifact on wall as curiosity, which is all it's good for
now.  Let the wave air out a little (this won't fry it).

A great way of trashing obsolete but confidential CD's, and perhaps the
cypherpunk equivalent of flushing the dope stash.

Tim O.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Sun, 15 Nov 92 13:58:13 PST
To: oren@apple.com
Subject: Re: Apple including PKS?
Message-ID: <9211152157.AA22323@servo>
MIME-Version: 1.0
Content-Type: text/plain


After reading the details of that (formerly) secret back-room agreement
between NSA and SPA, I don't think I'll *ever* trust a commercial
encryption package, especially one for which source code is unavailable
for scrutiny.

I've learned an important lesson in this business. You can never depend on
someone else to ensure your privacy. You have to do it yourself.

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Sun, 15 Nov 92 17:29:37 PST
To: cypherpunks@toad.com
Subject: Extortion Explosion
Message-ID: <9211160130.AA12418@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


			Extortion Explosion


Introduction:

Governments are in the extortion-and-protection racket, as are some well-known
smaller ventures. Why do these major organizations spend effort on protecting,
instead of just extorting? Current protection rackets maintain a monopoly and
manage "their" resources for sustained yield. Without protection, their
revenues would decline through a tragedy of the commons mechanism. Other
rackets would threaten the same victims, piling extortion on extortion, until
the economic field is bare.

Crypto technologies promise to liberate us from government extortion and the
"protection" of victimless crime laws by enabling the growth of a new sphere
of economic activity based on voluntary, secret transactions. But are these
technologies so limited in their power? 

New opportunities in the extortion industry:

Old problem: the victim may inform the police, making it risky to pick up the
money, which will likely be watched.
     New solution: demand payment via cryptomoney.

Old problem: if you build a reputation for carrying out your threats,
parasitic competitors can issue threats in your name, collecting while your
reputation is good but destroying your reputation by not following through on
threats.
     New solution: authenticate your threats and demands with digital
signatures.

Old problem: you may be caught firebombing the house, shooting the victim,
slashing the victim's daughter's face, or whatever; if you subcontract to a
thug, the thug may be caught and inform on you.
     New solution: use cryptomoney (and a reputation for paying) to hire thugs
while maintaining anonymity.

Old problem: providing protection, so that you keep a supply of economically
viable victims from whom to extort.
     New solution: Please find one! If the government can't protect victims
from you, how can you protect them from competitors?

     If this analysis is correct, then crypto technologies will make extortion
a highly profitable growth industry, making the security of property and
persons (outside tightly-knit walled communities?) incompatible with the
continued existence of free computer networks as we know them. Rather than
suffering from a single oppressor with an incentive to keep us productive, we
would become prey to an unbounded number, each competing to strip our assets
before they vanish. Society will surely suppress free networks once this
starts to happen; the harder it is to suppress free networks, the greater the
oppression will be.

Some objections and answers:

Q:Isn't it too bleak and pessimistic to believe that the best we can do is to
help our oppressors to maintain their monopoly on oppressing us?
A1: The Soviet Union was established as a result of a movement that aimed to
overthrow an oppressive order. Millions then died under an even more
oppressive order. This was bleak, but it happened anyway.
A2: Better one oppressor than many, all competing to be the first to kill and
eat the goose, knowing that they can't get the golden eggs anyway.
A3: Profit is a powerful motive, and conventional profitable activities are
imitated and expanded until demand saturates. Crypto-extortion should be
highly profitable, but the "supply" is delivered by force, so there is no
problem with competitors saturating the "demand" until the victims are drained
quite dry. This gives grounds for pessimism.

Q: Doesn't the enormous potential of this technology for expanding liberty
outweigh these theoretical dangers? What about our hopes and dreams, our
vision of a better world?
A: These hopes spring from a theoretical social and economic analysis of the
impact of crypto technologies, and cryptomoney in particular. The above line
of reasoning extends the same analysis. I hope it is wrong, and would be
greatly relieved to hear a convincing reason for dismissing it. If it stands,
the prospect seems to be either the destruction of society by free networks,
or the destruction of free networks by society. The longer we can postpone
this choice, the better.

Q: Won't cryptomoney be so hard to establish that there's no point in worrying
about this?
A: If so, then there is equally well no benefit in attempting to implement it.
The question is, are there any conditions for "success" that don't generate
disaster? Saying the gun probably isn't loaded isn't an argument for putting
it to your head and pulling the trigger.

Q: Isn't it too late to stop these technologies?
A: For public key communication (secrecy and authentication), probably yes.
For cryptomoney, possibly no. Most of the benefits of crypto technology seem
to come from the former, and most of the danger of an extortion explosion
seems to come from the latter.

Wishful thinking in the pursuit of liberty is no virtue; realism in the
defense of imperfect liberty is no vice. Free-lance oppression isn't freedom,
and I don't want it.

Cassandra
9531290065272860

P.S. Your neighbor didn't pay me, and his house is ash. Will you pay me? All I
ask this month is $100, which you can well afford. (Next month is negotiable,
and I can't speak for my competitors.)






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Sun, 15 Nov 92 19:09:16 PST
To: cypherpunks@toad.com
Subject: Extortion Explosion
Message-ID: <9211160310.AA14098@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


Cheer up, Cassandra!  Things aren't all that bad.

> New opportunities in the extortion industry:
> 
> Old problem: the victim may inform the police, making it risky to pick up the
> money, which will likely be watched.
>      New solution: demand payment via cryptomoney.

Many forms of electronic money can be traced if there is cooperation
between the payer and the bank.  For example, in "Untraceable Electronic
Cash", by Chaum, Fiat, and Naor, in Crypto 88, we find Alice withdrawing
money from the bank, re-blinding it, and developing a "digital coin", C.
She then pays that to Bob, who deposits C in the bank.  The protocol
goes to great length to protect Alice, so that the bank can't link C
with her account.  However, if she simply _tells_ the bank the value of C,
then when Bob goes to deposit it, he can get caught.

> Old problem: if you build a reputation for carrying out your threats,
> parasitic competitors can issue threats in your name, collecting while your
> reputation is good but destroying your reputation by not following through on
> threats.
>      New solution: authenticate your threats and demands with digital
> signatures.

I can't imagine that this is a big problem right now - people falsely
claiming to represent Big Willie when they actually don't, and trying
to extort money based on Willie's fearsome reputation.  That sounds like
a dangerous business.  So reducing this "problem" won't make much of
a difference.

> Old problem: you may be caught firebombing the house, shooting the victim,
> slashing the victim's daughter's face, or whatever; if you subcontract to a
> thug, the thug may be caught and inform on you.
>      New solution: use cryptomoney (and a reputation for paying) to hire thugs
> while maintaining anonymity.

Well, if thugs know that they are now going to be taking the sole
responsibility for their actions, without the safety of knowing that
they can rat on their employer if worse comes to worst, then they'll
charge more to make up for the greater risk.  This will make extortion
less profitable.

> Old problem: providing protection, so that you keep a supply of economically
> viable victims from whom to extort.
>      New solution: Please find one! If the government can't protect victims
> from you, how can you protect them from competitors?

This is the key point.  What stops protection rackets now?  Is it really
the points listed above: that the money may be traced, that others may
falsely benefit from my reputation, that thugs may inform on me?  What
about simple physical surveillance of property?  What about revenge on
the transgressors?  (As above, the revenge would be restricted to the
thugs who did the job, but if it was bad enough it would still have a
strong deterrent effect.)

> Wishful thinking in the pursuit of liberty is no virtue; realism in the
> defense of imperfect liberty is no vice. Free-lance oppression isn't freedom,
> and I don't want it.
> 
> Cassandra
> 9531290065272860

It makes more sense to have good fire and police forces to deal with
the bad guys than to get all in a tizzy because the bad guys can talk
to each other now without getting caught.

Polyanna 
---   Undressed PGP public key.  Dress it up yourself.   ---
mQA9AisGm6sAAAEBgLsub7XIi32DjNFKJmGFajDNNIeql4RBmHG/mh9Ns58aBgMv
wGRi0KkZ0YIYZZnLpwAFEbQkUG9seWFubmEsIGMvbyA8Y3lwaGVycHVua3NAdG9h
ZC5jb20+
=uoWN






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Sun, 15 Nov 92 19:43:32 PST
To: oren@apple.com
Subject: Rander box and other stuff
In-Reply-To: <9211152148.AA24934@apple.com>
Message-ID: <9211160343.AA11287@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


    >I have a question regarding the ideas which have been circulating
    >about using CD ROMs as key storage.  How does one go about
    >rapidly and effectively erasing everything on a CD ROM?


  A lab proven method:  Take CD-ROM.  Place in standard kitchen microwave. 
  Set on high power cook for 5 seconds.  Press start.  Watch the action. 
  Hang resulting artifact on wall as curiosity, which is all it's good for
  now.  Let the wave air out a little (this won't fry it).

You should know better than this.  Microwaving cracks the aluminum
coating into a lot of small pieces, but almost all the pieces are
larger than a few square mm. even if you cook until quite "well done".
A few mm. of a CD is a *lot* of contiguous bits that could be
recovered by a determined enough adversary, and you likely wouldn't
ebe bothering with OTP's unless you're concerned with very determined
adversaries.

I agree with the person who griped that OTP's are making excessive
list traffic compared with interesting protocols, etc.
OTP's get rehashed on sci.crypt every few months, as that person
pointed out.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sun, 15 Nov 92 17:37:40 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Why remailers...
Message-ID: <921116013001_74076.1041_DHJ41-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


Tim mentioned that not many people on the list have expressed
interest in the remailers, and it occurs to me that maybe people
don't all share the vision of why this crypto technology is important.

I'm trying to recall how I learned about the possibilities of this
technology.  I recall reading "True Names" a few years ago.  Vinge had
his netters exchanging mail anonymously.  The hero downloaded a big
batch of messages from a BBS and tried decrypting all of them to see
which were for him.  Okay, I thought, that would be a way of disguising
which messages you were _receiving_.  Then Vinge said something like
"and using more elaborate techniques, the sender of a message could
be hidden as well."  Hold on, I thought.  That will never work.  If
they tap your line, they're going to know exactly what messages you're
sending.  Too bad.  Vinge had a clever idea going, but it's flawed.

I only learned about Chaum's crypto stuff last year.  Somebody on the
Extropians list mentioned PGP, and I'd always had a casual interest
in crypto, so I downloaded it and played with it some.  I thought it
was great and really got into it in a big way.

This got me interested in crypto in general, so I started doing some
library research.  When I found Chaum's stuff, it just blew me away.
The first article I found, I think, was his CACM paper which is an
overview of many of the things that are possible.  I started trying to
track down other papers by Chaum.  Here were all the technologies
needed to make Vinge's world work, technologies which Vinge apparently
knew about long before I did.

It seemed so obvious to me.  Here we are faced with the problems of
loss of privacy, creeping computerization, massive databases, more
centralization - and Chaum offers a completely different direction to
go in, one which puts power into the hands of individuals rather than
governments and corporations.  The computer can be used as a tool to
liberate and protect people, rather than to control them.  Unlike the
world of today, where people are more or less at the mercy of credit
agencies, large corporations, and governments, Chaum's approach balances
power between individuals and organizations.  Both kinds of groups are
protected against fraud and mistreatment by the other.

Naturally, in today's society, with power allocated so disproportionately,
such ideas are a threat to large organizations.  Balancing power would
mean a net loss of power for them.  So no institution is going to pick
up and champion Chaum's ideas.  It's going to have to be a grass-roots
activity, one in which individuals first learn of how much power they
can have, and then demand it.

Where do the remailers fit in?  They represent the "ground floor" of this
house of ideas - the ability to exchange messages privately, without
revealing our true identities.  In this way we can engage in transactions,
show credentials, and make deals, without government or corporate databases
tracking our every move as they can today.  Only by securing the ability to
communicate privately and anonymously can we take the next steps towards
a world in which we each have true ownership and control over information
about our lives.

Chaum's ACM paper is titled, provocatively, "Security Without Identification -
Transaction Systems to Make Big Brother Obsolete."  The work we are doing
here, broadly speaking, is dedicated to this goal of making Big Brother
obsolete.  It's important work.  If things work out well, we may be able
to look back and see that it was the most important work we have ever done.

Hal Finney
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Sun, 15 Nov 92 18:43:30 PST
To: cypherpunks@toad.com
Subject: Chaum's papers
Message-ID: <9211160243.AA07165@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



Hal Finney writes:
> This got me interested in crypto in general, so I started doing some
> library research.  When I found Chaum's stuff, it just blew me away.

What else has Chaum written about?  I saw his Scientific American
cryptomoney article, and have heard of his dc-nets, but what other
protocols has he discussed?  Any pointers on journal articles would be
appreciated - I think tomorrow I'll hit the library and go sifting for
everything Chaum has written!

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sun, 15 Nov 92 22:27:49 PST
To: cypherpunks@toad.com
Subject: re: Why remailers...
Message-ID: <3744.2B07398C@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain




 U> From: 74076.1041@CompuServe.COM (Hal)

re: why remailers aren't as exciting as RNG's.

Well, remailers are working, admittedly a bit clunky at the moment,
and RNGs being talked about aren't. And we're primarily hackers. Once
something's working, it's less interesting, no? :-)

The next step for remailers is to make them actually *usable*,
routinely. Their current status is no fault of the implementors, it's
a first pass and a test bed (I ain't complaining!)

I just don't think it's a big secret, nor a big problem. Development
is always slow and boring... :-)


--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Sun, 15 Nov 92 22:27:50 PST
To: cypherpunks@toad.com
Subject: re: Rander box and other stuff
Message-ID: <3745.2B07398E@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U>   A lab proven method:  Take CD-ROM.  Place in standard 
 U> kitchen microwave.    Set on high power cook for 5 
 U> seconds.  Press start.  Watch the action.

If its a CD ROM, then there's a bunch of them. Someone else will have
a copy. Aternately, Iif you mark which keys are used, then it will be
detectable which keys were used (sic). It would be better to have all
of the CD ROMs laying about, untouched, and secret the key-selection
elsewhere. 



PS: I get lots of really bad CDs in the mail, from the days when I was
doing HOMOCORE zine. I used to save up big stacks of them and try to
trade them in at used record stores. They are all so awful (eg.
bottom-rotation gunk on "modern rock" stations.) that the stores
won't take them! 

I now nuke 'em. Far more fun!

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Mon, 16 Nov 92 00:59:25 PST
To: oren@apple.com
Subject: Re: Rander box and other stuff
Message-ID: <199211160858.AA23576@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


So we need to set up UPSs (uninterruptable power supplies, i.e. backup
power) for our u-wave ovens, and build a standard interface which will set
the appropriate parameters (5 sec on high cook) and start, which can be
connected to a burglar alarm with panic switches and keypad with duress
code.  Then if the barbarians come to the door, it's one-two-three-FLUSH!

Somewhat inconvenient if the barbarians come a-callin' when you're in the
middle of a crypto session ("'scuse me while I put something in for
dinner...") but doable...

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Mon, 16 Nov 92 01:13:51 PST
To: cypherpunks@toad.com
Subject: The Dining Cryptographers Protocol
Message-ID: <9211160910.AA13370@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Fellow Dining Cryptographers (and Cypherpunks),

Hal Finney has been suggesting I forward to this list some articles I
wrote for another list of like-minded folks, the "Extropians" list. We
had some fascinating discussions of digital money, DC-nets, digital
pseudonyms (a la Vernor Vinge's "True Names," as Hal has noted), etc.
Basically the stuff I put in my .signature, and so on.

These topics are, in my opinion, at the core of what we are doing on
this list. It is highly gratifying to see the pieces falling into
place. And at our crypto session  at the Hackers Conference, it became
clear to many people just how close we are.

So since Hal just forwarded me one of my old postings, how can I
resist? (I still _have_ my old posts, but no longer on my NETCOM
system, so reposting them takes a bit of effort. So I'll just forward
to you the posting Hal just forwarded to me!)

Hal Finney writes:

I was looking through some old Extropians messages and found this
one which you wrote about DC nets.  I don't know if you archive your
old messages, but I thought this had some good stuff, especially at the
end where you talk about the applications of crypto anonymity.  You
would probably want to change the use of Extropians to Cypherpunks or
some such, if you wanted to re-post it there.

Hal


Return-Path: <uunet!gnu.ai.mit.edu!extropians-request>
To: Extropians@gnu.ai.mit.edu
From: uunet!netcom.com!tcmay (Timothy C. May)
Subject: Dining Cryptographers
X-Original-To: Extropians@gnu.ai.mit.edu
Date: Tue, 18 Aug 92 15:45:34 PDT
X-Extropian-Date: Remailed on August 18, 372 P.N.O. [22:46:47 UTC]
Reply-To: uunet!gnu.ai.mit.edu!Extropians

Marc R. has opened the door for me to get into some really exciting
stuff:
> 
> Tim May mentioned a new method from Chaum for defeating traffic analysis:
> 
> > Chaum has since improved the tamper-responding "mix" by going to a pure
> > software scheme which he calls "the Dining Cryptographers Protocol." It's
> > described in Vol. 1, Number 1 of "Journal of Cryptology," 1988. If there's
> > interest, I'll summarize it.
> 
> Yes, please, Tim!
> 
> 
> M.

Complexity Warning: This stuff (I'm being informal) is easy once you
get the basic idea. But getting the basic idea usually involves reading
several articles on what RSA, digital signatures, etc., are all about,
working out some examples, thinking about it, drawing pictures with
other folks, and finally having an "Aha!" experience (in Werner Erhard's
terms, you "get it"). The ASCII nature of the Net is not conducive to learning
this stuff, despite the excellent summaries of crypto by Marc R. and Perry M.

The almost-latest "Scientific American," August, has an article by David Chaum
on digital money, and the latest "Spectrum," available at selected newstands,
has several articles on security and cryptography. Also, there are lots of
books. Look 'em up in a university library or flip through them at a large
technical bookstore and pick the one you like the most. (I like a slim
Springer-Verlag paperback, "Modern Cryptology," by Gilles Brassard, 1988, as
a good intro to "modern"--as opposed to "classical"--crypto.)

If the stuff in this posting, and on crypto in general, is beyond your
current understanding, either ignore it, skim it and try to get the gist,
or dig into the articles and books. 

Anyway, back to "The Dining Cryptographers Problem: Unconditional Sender and
Recipient Untraceability," David Chaum, Journal of Cryptology, I, 1, 1988.
Since this journal is hard to get, I'll discuss the article in some detail.
(The techniques have major implications for anarchocapitalism and for
Extropian ideas.)

Abstract: "Keeping confidential who sends which messages, in a world where any 
physical transmission can be traced to its origin, seems impossible.
The solution presented here is unconditionally or cryptographically secure,
depending on whether it is based on one-time-use keys or on public keys.
respectively. It can be adapted to address efficiently a wide variety of 
practical considerations."

A word on terminology: "Unconditionally secure" means what it says: no
computer will ever crack it. One-time pads are unconditionally secure...no
code or cipher is involved, except the one-time pad, so the message is
secure as long as the pad has not been compromised. "Cryptographically
secure" means secure so long as various crypto ciphers are secure, which
may be for a very, very long time (e.g., with very large primes, in RSA).

Chaum describes some "dining cryptographers," which I will playfully change
to "dining Extropians." (The term is of course a variant of the seminal
"dining logicians problem" in computer science)

Three Extropians are having dinner, perhaps in New York City. Their waiter
tells them that their bill has already been paid, either by the NSA
or by one of them. The waiter won't say more.

The Extropians wish to know whether one of them paid, or the NSA paid. But
they don't want to be impolite and force the Extropina payer to 'fess up,
so they carry out this protocol (or procedure):

Each Extropian flips a fair coin behind a menu placed upright between himself
and the Extropian on his right. The coin is visible to himself AND to the
Extropian on his left. Each Extropian can see his own coin and the coin to his
right.

STOP RIGHT HERE! Please take the time to make a sketch of the situation I've
described. If you lost it here, all that follows will be a blur. I'm sparing
you folks my attempt at an ASCII drawing!

Each Extropians then states out loud whether the two coins he can see are the
SAME or are DIFFERENT, e.g., "Heads-Tails" means DIFFERENT, and so forth. For
now, assume the Extropians are truthful.

A little bit of thinking shows that the total number of "DIFFERENCES" must
be either 0 (the coins all came up the same), or 2. Odd parity is impossible.

Now the Extropians agree that if one of them paid, he or she will SAY THE
OPPOSITE of what they actually see. Remember, they don't announce what their
coin turned up as, only whether it was the same or different as their neighbor.

Suppose none of them paid, i.e., the NSA paid. Then they all report the truth
and the parity is even (either 0 or 2 differences). They then know the NSA
paid.

Suppose one of them paid the bill. He reports the opposite of what he actually
sees, and the parity is suddenly odd. That is, there is 1 difference reported.
The Extropians now know that one of them paid. But can they determine which
one?

Suppose you are one of the Extropians and you know you didn't pay. One of the
other two did. You either reported SAME or DIFFERENT, based on what your 
neighbor to the right (whose coin you can see) had. But you can't tell which
of the other two is lying! (You can see you right-hand neighbor's coin, but
you can't see the coin he sees to his right!)

This all generalizes to any number of people. If none of them paid, the parity
is even. If one of them paid, the parity is odd. But which one of them paid
cannot be deduced. And it should be clear that each round can transmit a bit,
e.g., "I paid" is a "1". The message "Attack at dawn" could thus be "sent"
untraceably with multiple rounds of the protocol.

The Crypto Ouija Board: I explain this to people as a kind of ouija board.
A message, like "I paid" or a more interesting "Transfer funds from.....,"
just "emerges" out of the group, with no means of knowing where it came 
from. Truly astounding.

Now there are many interesting wrinkles and elaborations to this protocol. I'll
note just a few.

1. Collusion. Obviously the Extropians can collude to deduce the payer. 
This is best dealt with by creating multiple subcircuits (groups doing the 
protocol amongst themselves). Lots more stuff here. Chaum devotes most of the
paper to these kind of issues and their solutions.

2. With each round of this protocol, a single bit is transmitted. Sending
a long message means many coin flips. Instead of coins and menus, the 
neighbors would exchange lists of random numbers (with the right partners,
as per the protocol above, of course. Details are easy to figure out.)

3. Since the lists are essentially one-time pads, the protocol is 
unconditionally secure, i.e., no assumptions are made about the difficulty
of factoring large numbers or any other crypto assumptions.

4. Participants in such a "DC-Net" (and here we are coming to the heart
of the "crypto anarchy" I have mentioned several times, and which is
perhaps foolishly advertised in my .sig) could exchange CD-ROMs or DATs,
giving them enough "coin flips" for zillions of messages, all untraceable!
The logistics are not simple, but one can imagine personal devices, like
smart card or Apple "Newtons," that can handle these protocols (early 
applications may be for untraceable brainstorming comments, secure
voting in corportate settings, etc.)

5. The lists of random numbers (coin flips) can be generated with standard
cryptographic methods, requiring only a key to be exchanged between the 
appropriate participants. This eliminates the need for the one-time pad,
but means the method is now only cryptographically secure, which is 
often sufficient. (Don't think "only cryptographically secure" means
insecure....the messages may remain encrypted for the next billion years)

6. Collisions occur when multiple messages are sent at the same time. Various
schemes can be devised to handle this, like backing off when you detect
another sender (when even parity is seen instead of odd parity). In large 
systems this is likely to be a problem. Solutions are left as an exercise.

7. Noise. Some participants may try to flood the circuit with spurious
messages, to defeat the system or for whatever other reasons. This is
still an issue. (If there's anything to take away from crypto, it's that
nothing is as simple as it looks, that there are always devious ways to 
spoof, jam, and forge. I expect you've seen this from some of the debate
on digital voting schemes.)

What Can "DC-Net" Be Used For?:

* Untraceable mail. Useful for avoiding censorship, for avoiding lawsuits,
and for all kinds of crypto anarchy things.

* Fully anonymous bulletin boards, with no traceability of postings or 
responses. Illegal materials can be offered for sale (my 1987 canonical
example, which freaked out a few people: "Stealth bomber blueprints for
sale. Post highest offer and include public key."). Think for a few minutes
about this and you'll see the profound implications.

* Decentralized nexus of activity. Since messages "emerge" (a la the ouija
board metaphor), there is no central posting area. Nothing for the government
to shut down, complete deniability by the participants.

* Only you know who your a partners are....in any given circuit. And you can
be in as many circuits as you wish. (Payments can be made to others,
to create a profit motive. I won't deal with this issue, or with the issue
of how reputations are handled, in this posting.)

* The tamper-responding "digital mixes" can still be useful, and may supplement
this purely software-based approach.

* Digital money gets involved, too, both for payments in this system, and in
terms of "alternative currencies." I'm not an economist, so I'll leave this 
for others to go into in more detail.

Enough for now. Chaum's work is just the start. These systems can initially be
set up for "innocuous" purposes like research into crypto techniques (not yet
banned in the U.S.), role-playing games, religions, and the like. Once
they get going, it'll be too late to stop the other things.

Hope you liked this summary. Please read the articles...there's just no way
my posting can do justice to them (though I admit I've concentrated my efforts
on the political aspects, which "respectable" crypto researchers rarely
mention, so perhaps the flavor here is a bit more Extropian than you'll
find elsewhere.)

--Tim (part of the "Too Many Tims!" Conspiracy)

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Mon, 16 Nov 92 01:45:42 PST
To: markoff@nyt.com
Subject: Cryptographer jailed for selling crypto to political opposition?
Message-ID: <9211160945.AA19475@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Date: Sun, 15 Nov 92 02:17:47 -0500
From: barlow@icecube.pinedale.wy.us (John Perry Barlow)
Message-Id: <9211150717.AA00755@icecube.pinedale.wy.us>
To: gnu@toad.com
Subject: Here's one to pass on to CypherPunk

Begin forwarded message:

Date: Sun, 15 Nov 1992  2:53:58 UTC+0100
From: "(Miguel Gallardo)" <gallardo@batman.fi.upm.es>
Subject: Cryptodanger!!!
To: barlow@eff.org, barlow@icecube.pindale.wy.us, postmaster@eff.org

Dear friends,
 
I think that paranoid is almost inevitable in
Cryptology. The real danger is just trying to avoid that
thinking. But sometimes things are really difficult!  

One year ago I met a man in a conference on Cryptology. He
was from Switzerland and was working for a company named
CRYPTO AG. He is fluent in several lenguages, including
Spanish and Arabic, and was not afraid about his interest
in taboo (cryptoanalysis). I really enjoyed that
conversation.   Last week I listened a conversation about
him, and I know now that he is in jail at Teheran (Iran). He
is acused for atenting against the shii goverment just
because he was sellin cryptology to the political
opposition.   

Do you know about that? If so, do you have
anything published on it?   

His name is Hans Buhler, CRYPTO
AG, P.O. Box 474 CH-6301 Zug/Switzerland.   

I am really interested in any information about him!   Nobody answer
my fax to his company, or to Iran embassy here (!?). 

      _ _ _               _    
     ' ) ) )             // 
      / / / o __     _  // 
     / ' (_<_(_//_/_</_</_ 
             _/ 

     Miguel A. Gallardo Ortiz (Unix&C freelance, working on cryptology)
Personal address&phone:
     C/ Fernando Poo 16
     E-28045 Madrid (Spain)
     Telephone: (341) 474 38 09
     FAX:             473 81 97







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Mon, 16 Nov 92 01:47:48 PST
To: cypherpunks
Subject: Balancing National Interests
Message-ID: <9211160947.AA19535@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Date: Sat, 14 Nov 1992 20:17:06 -0500
To: interesting_people@aurora.cis.upenn.edu
From: Dave Farber <farber@central.cis.upenn.edu>
Subject: from RISKS

Reprinted with permission ("do with it as you wish.  Granger") 

A "Viewpoint " piece in  The Institute, November 1992

Balancing National Interests

  The September/October issue of The Institute carried a front page story
reporting that the Federal Bureau of Investigation is promoting legislation
that would require all telephone systems to be designed in such a way that they
can be wiretapped by law enforcement officials.  The argument is that
wiretapping is a key tool in much of law enforcement, particularly in fields
such as drugs, racketeering, conspiracy and white collar crime, and that unless
care is taken in the design of future telecommunications systems, this tool may
become difficult or impossible to exercise.  To solve this problem the FBI is
promoting legislation that would establish design requirements on future
telephone systems.  Not surprisingly, civil liberties groups and telephone
companies are reported to be less than enthusiastic.

        While interesting and important in its own right, this controversy is
perhaps even more important as a symbol of a broader set of conflicts between a
number of important national interests. As a country, we want to promote:

  * Individual privacy (including the right of citizens and other residents of
the U.S. to keep personal records private, hold private communications with
others, and move about without being "tracked".)

  * Security for organizations (including protection of financial transactions,
and the ability to keep corporate data, plans, and communications
confidential.)

  * Effective domestic law enforcement (including the ability to perform
surveillance of legitimately identified suspects, and the ability to audit and
reconstruct fraudulent activities.)

  * Effective international intelligence gathering (including the ability to
monitor the plans and activities of organizations abroad that may pose a threat
to the U.S. or to other peaceful states and peoples.)

  * Secure world-wide reliable communications for U.S. diplomats and the
military, for U.S. business, and for U.S. citizens in their activities all
around the world (including the ability to maintain and gain access to secure,
reliable, communications channels.)

        Just as with most of our society's other fundamental objectives, these
objectives are in conflict.  You can not maximize them all because getting more
of some involves giving up some of others.  A dynamic tension must be created
that keeps the various objectives properly balanced.  That socially optimal
point of balance may change gradually over time as world conditions and our
society's values evolve.

        An electrical engineer who thinks for a moment about the problem of
achieving any particular specified balance among the various objectives I have
listed will quickly conclude that communications and information technology
design choices lie at the heart of the way in which many of the necessary
tradeoffs will be made.  We would like easy portable communications for all,
but doing that in a way that allows people to keep their legitimate travels
private poses significant design challenges.  Banks and other businesses would
like secure encrypted communications world-wide, but promoting the general
availability of such technologies all around the world severely complicates the
signal intelligence operations of intelligence organizations.

        The troubling thing about the FBI's legislative proposals is not that
they are being made, but that we lack a broader institutional context within
which to evaluate them.  In making such choices, we need to look systematically
at all the legitimate interests that are at stake in telecommunications and
information technology design choices, consider the ways in which technology
and the world are evolving, and integrate all these considerations to arrive at
a reasoned balance.  In the old days, if things got too far out of line in some
balance (for example, between freedom of the press and protection against
liable), the courts simply readjusted things and we went on.  Today, and
increasingly in the future, with many of these balances hard wired into the
basic design of our information and communication systems, it may be much
harder to readjust the balance after the fact.

        There are several organizations that should be working harder on these
issues.  On the government side the Telecommunication and Computing
Technologies Program in the Office of Technology Assessment should be doing
more systematic studies of these tradeoffs to help inform the Congress; The
National Telecommunications and Information Administration in the Department of
Commerce (or some appropriate interagency committee) should be doing similar
studies to develop more coherent and comprehensive executive branch policy; and
the Office of Policy and Plans in the Federal Communications Commission (which
is an independent regulatory agency not directly subject to executive branch
policy) should be giving these issues more attention so it can better support
the Commissioners when they confront such tradeoffs.  On the non-government
side, the Office of Computer and Information Technology at the National
Research Council might appropriately mount a comprehensive study.  There is an
ideal opportunity here for a private foundation to fund an independent
blue-ribbon commission.  Finally, the computer and telecommunications
industries, both individually and collectively through their industry
associations, should be taking more interest in how the country will strike
these all important balances.
                                                        M. Granger Morgan

M. Granger Morgan (F) is head of the Department of Engineering and Public
Policy at Carnegie Mellon University where he is also a Professor in the
Department of Electrical and Computer Engineering and in the H. John Heinz III
School of Public Policy and Management.  He teaches and performs research on a
variety of problems in technology and public policy in which technical issues
are of central importance.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sun, 15 Nov 92 23:37:38 PST
To: Cypherpunks <cypherpunks@toad.com>
Subject: Chaum's papers
Message-ID: <921116073129_74076.1041_DHJ35-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


A couple of people have asked for references to Chaum's papers.
The August, 1992 issue of Scientific American was mentioned here, I think.
 
The ACM paper I referred to is "Security Without Identification:
Transaction Systems to Make Big Brother Obsolete", October 1985.
 
The "DC-Net" is described in "The Dining Cryptographers Problem:
Unconditional Sender and Recipient Untraceability", Cryptology, 1988,
volume 1, p65-75.
 
The "Mix-net", which is similar to the remailers we are experimenting
with, is described in "Untraceable Electronic Mail, Return Addresses,
and Digital Pseudonyms", CACM, February, 1981.
 
Chaum also frequently presents papers at the Crypto conferences, so
if you can get access to the proceedings of these at the library you
will usually find one or two papers by him in each volume.  However,
in recent years he has published on other topics which don't seem as
relevant to the freedom/privacy issues we are concerned with.
 
Hal
74076.1041@compuserve.com
 






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Mon, 16 Nov 92 03:31:18 PST
To: markoff@nyt.com
Subject: Re:  Cryptographer jailed for selling crypto to political opposition?
Message-ID: <199211161129.AA29310@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Crypto AG is the current name of the Hagelin company, which was founded by
Boris Hagelin shortly before WW2.  Hagelin's main contribution was the
advancement of the mechanical rotor system; their M-209 was a basic part of
Allied battlefield operations.  This machine was about the size of a desk
phone base, and had a little knob which you'd turn to the letter you wanted
to enter, one letter at a time, and after each letter you'd press a handle,
whicc would operate the mechanism and printo out both a cleartext and
ciphertext strip on paper.  The ciphertext would be handed to the radio
operator to be sent in morse (or in civilian use, via telegraph land-lines).

Hagelin made various versions of their basic rotor machine.  One was a
pocket-sized unit, like 3" x 5", with a rotary alphabetic dial on the front.

Hagelin supplied most of the noncommunist world with crypto tech after WW2.

Chances are that Crypto AG has sufficient connexions in high places as to be
able to get its people out of there.  I'm familiar with another case
involving a large northern Euro maker of telecom systems who had two
engineers taken hostage in Iraq on some inflated charge, and sentenced to 7
years... the company fully expects to have its engineers out of there within
six months, no question about it.    

-gg@well.sf.ca.us





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 16 Nov 92 09:12:39 PST
To: cypherpunks@toad.com
Subject: November 21 meeting, 12 noon, at Cygnus offices
Message-ID: <9211161712.AA15115@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



ANNOUNCEMENT
============

The Third Physical Cypherpunks Meeting: Project Planning


    It has become clear that lots of code needs to be written, and
that we will be writing it.  Therefore the Third Meeting will be
devoted to project planning and design review.


Date: November 21
Time: 12 noon
Where: Cygnus Support offices
Who: you, and anybody you know who wants to come, and so on.  (Please
    do not post this announcements to public places, but do encourage
    private circulation.)
Positive-Confimation:  Please tell me if you are coming.  Replies to
    hughes@soda.berkeley.edu.


Please, I urge all of you on the list that can make to attend this
time.  This will be a pivotal meeting, since we are deciding
priorities here.  If you want to affect the course of development, you
ought to show up.  If you can't attend, corner someone on the list who
will be there and convince them to represent your position.

Eric Hughes



AGENDA
======

1.  Key exchange.  Bring a diskette with your PGP public key on it.
Bring a machine which can read this diskette.  Bring extra diskettes
to collect keys on and to give out.  Let us not be hypocrites and let
us all know each other's public keys.

2.  Project planning.  We need a list of crypto projects and who is
working on them.  This will help coordination and avoid duplication of
effort.  We need to prioritize the projects to avoid premature
development.  We need to create strategies and design criteria.

3.  Project logistics.  We need to talk about the best ways to do
widely distributed software development in this fairly anarchic
environment.

4.  Design review.  Hal Finney and I have been duking it out behind
the scenes working on a design schema for the next generation
remailer.  I'd like to present the design and have people critique it.

(would be 5.) We won't be playing the crypto-anarchy game this time.
It's not a dead duck, but this time we've got more urgent things to
do.


DIRECTIONS
==========

Here is a reposting of the directions to the meeting place. 
------------------------------------------------------------------
To: cypherpunks@toad.com
Subject: Better directions to the meeting on Saturday at noon
From: gnu@cygnus.com

Someone asked for better directions, and the original ones were
pretty skimpy anyway.  Here's a better try.

	Cygnus Support
	1937 Landings Drive
	Mt. View, CA  94043

There's no phone service there yet.

Take US 101 toward Mt. View.  From San Francisco, it's about a
40-minute drive.  Get off at the Rengstorff Ave/Amphitheatre Parkway
exit.  If you were heading south on 101, you curve around to the
right, cross over the freeway, and get to a stoplight.  If you were
heading north on 101, you just come right off the exit to the
stoplight.  The light is the intersection of Amphitheatre and
Charleston Rd.  Take a right on Charleston; there's a right-turn-only
lane.

Follow Charleston for a short distance.  You'll pass the
Metaphor/Kaleida buildings on the right.  At a clump of palm trees and
a "Landmark Deli" sign, you can take a right into Landings Drive; this
gets you into the complex from the north.  Or you can go slightly
further along Charleston and take the next right, into a driveway with
a big "Landmark" sign in the middle.  No matter which way you got into
the complex, follow around it until you are on the side that faces the
freeway.  There's a clock tower that rises out of one of the
buildings, to the right (south) of the deli.  Enter through the doors
immediately under the clock tower.  They'll be open between noon and
1PM at least.  (See below if you're late.)

Once inside, take the stairs up, immediately to your right.  At the top
of the stairs, turn right past the treetops, and we'll be in 1937 on 
your left.

If you are late and the door under the clock tower is locked, you can
go to the deli (which will be around a building and left, as you face
the door), cut between the buildings to the right of the deli, and
into the back lawns between the complex and the farm behind it.  Walk
around the buildings until you see a satellite dish in the lawn.  Go
up the stairs next to the dish, which are the back stairs into the
Cygnus office space.  We'll prop the door (or you can bang on it if we
forget).

Or, you can find the guard who's wandering around the complex, who
knows there's a meeting happening and will let you in.  They can be
beeped at 965 5250, though you'll have trouble finding a phone.

Don't forget to eat first, or bring food at noon!  I recommend hitting
the burrito place on Rengstorff (La Costen~a) at about 11:45.  To get
there, when you get off 101, take Rengstorff (toward the hills) rather
than Amphitheatre (toward the bay).  Follow it about ten blocks until
the major intersection at Middlefield Road.  La Costen~a is the store
on your left at the corner.  You can turn left into the narrow lane
behind the store, which leads to a parking lot, and enter by the front
door, which faces the intersection.  To get to the meeting from there,
just retrace your route on Rengstorff, go straight over the freeway,
and turn right at the stoplight onto Charleston; see above.

See you there!

	John Gilmore







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Mon, 16 Nov 92 10:44:37 PST
To: "George A. Gleason" <gg@well.sf.ca.us>
Subject: Re: Rander box and other stuff
In-Reply-To: <199211160858.AA23576@well.sf.ca.us>
Message-ID: <9211161844.AA20421@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I heard something somewhere about hard disks with a layer of thermite
inside the platter.  Can you say "ferrous vapor"?

For me the ideal cryptosystem would be a small notebook with a thermite hard
drive and TEMPEST shielding and no multitasking.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Mon, 16 Nov 92 11:21:05 PST
To: Eric Hollander <hh@soda.berkeley.edu>
Subject: Re: Rander box and other stuff
In-Reply-To: <9211161844.AA20421@soda.berkeley.edu>
Message-ID: <9211161920.AA22901@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



>
>I heard something somewhere about hard disks with a layer of thermite
>inside the platter.  Can you say "ferrous vapor"?
>
>For me the ideal cryptosystem would be a small notebook with a thermite hard
>drive and TEMPEST shielding and no multitasking.
>

you forgot the auto self destruct if the unit is more then 4 meters from
your person. 


		-Pete




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Michael Gleibman <c0408982@techst02.technion.ac.il>
Date: Mon, 16 Nov 92 02:33:09 PST
To: cypherpunks@toad.com
Subject: Unsubscribe
Message-ID: <9211161029.AA14695@techst02.technion.ac.il>
MIME-Version: 1.0
Content-Type: text/plain


Unsubscribe me from this list, please, it is a huge value of mail:-)...
Thank you in advance.
c0408982@techst02.technion.ac.il




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Mon, 16 Nov 92 08:51:45 PST
To: cypherpunks@toad.com
Subject: Re: Apple including PKS?
Message-ID: <4195@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


Phil Karn says:
> 
> I've learned an important lesson in this business. You can never depend on
> someone else to ensure your privacy. You have to do it yourself.
> 

The same goes for the ultimate standard of physical security: defence
of one's person against physical attack.  Arguments for the right to
keep and bear arms can often be directly mapped onto arguments for the
right to keep and use pkeys.


Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
================ PGP 2.0 public key available =======================




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Date: Mon, 16 Nov 92 10:15:43 PST
To: cypherpunks@toad.com
Subject: Re: The Dining Cryptographers Protocol
Message-ID: <9211161815.AA29148@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


My spin on the Dining Cryptographers Protocol is, it's nifty and
theoretically strong, but in practice mixes are better for almost all uses.

If you have N people in a DC-net, you must exchange N bits of traffic per bit
of anonymous message transmitted.  If you use mixes and send each message on
M hops, you exchange M bits of traffic per bit of anonymous message 
transmitted.  N is typically 100-10000, and M is typically 2-10.  Mixes
are more efficient.

One advantage of DC-nets is that they're instant; with mixes there must be
some delays in order to accumulate enough cover messages to defeat traffic
analysis.



-- Marc Ringuette (mnr@cs.cmu.edu)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 16 Nov 92 11:26:52 PST
To: shawnb@ecst.csuchico.edu
Subject: The legality of PGP
In-Reply-To: <9211140007.AA19365@toad.com>
Message-ID: <9211161902.AA08397@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: S.E. Brown <shawnb@ecst.csuchico.edu>

>Well,

>I've been reading a lot of speculation and outright disinformation about
>the legality of PGP.  Does anyone have any informed information about the
>actual legal status us sing and disseminating the program?

PGP is based on RSA cryptography, which is patented. The patent is
controlled by Public Key Partners, which has not granted a license for
people to use PGP. Therefore, using PGP is possibly a patent
violation, although thus far no action seems to have been taken by PKP
in this respect.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tim Oren  <oren@apple.com>
Date: Mon, 16 Nov 92 14:47:57 PST
To: cypherpunks@toad.com
Subject: Digital Cash bibliography
Message-ID: <9211162247.AA24502@apple.com>
MIME-Version: 1.0
Content-Type: text/plain


As a followup to Tom's bibliography, here's a list I compiled about six
months ago on digital cash, including Chaum's basic articles, others
published in this area, and a list of relevant U.S. patents.  -  Tim O.

-----------

Bibliography for Digital Cash and Checks using Cryptographic Techniques

Articles

Chaum, D., Showing credentials without identification: transferring
signatures between unconditionally unlinkable pseudonyms. (Springer-Verlag,
Berlin, West Germany, p. 246-64, 1990)(Conference: Advances in
Cryptology-AUSCRYPT '90 International Conference on Cryptology.
Proceedings, Sydney, NSW, Australia, 8-11 Jan. 1990)

Chaum, D. den Boer, B. van Heyst, E. Mjolsnes, S. Steenbeek, A., Efficient
offline electronic checks. (Springer-Verlag, Berlin, Germany, p. 294-301,
1990)(Conference: Advances in Cryptology - EUROCRYPT '89. Workshop on the
Theory and Application of Cryptographic Techniques Proceedings, Houthalen,
Belgium, 10-13 April 1989)

Chaum, D., Online cash checks. (Springer-Verlag, Berlin, Germany, p.
288-93, 1990)(Conference: Advances in Cryptology - EUROCRYPT '89. Workshop
on the Theory and Application of Cryptographic Techniques Proceedings,
Houthalen, Belgium, 10-13 April 1989)

Chaum, David, Security without Identification: Transaction Systems to make
Big
Brother Obsolete; Communications of the ACM 28/10 (1985) 1030-1044.

Chaum, D. Fiat, A. Naor, M., Untraceable electronic cash. (Springer-Verlag,
Berlin, West Germany, p. 319-27, 1990)(Conference: Advances in Cryptology -
CRYPTO '88. Proceedings, Santa Barbara, CA, USA, 21-25 Aug. 1988)

Okamoto, T. Ohta, K., Disposable zero-knowledge authentications and their
applications to untraceable electronic cash. (Springer-Verlag, Berlin, West
Germany, p. 481-96, 1990)(Conference: Advances in Cryptology - CRYPTO '89.
Proceedings, Santa Barbara, CA, USA, 20-24 Aug. 1989)

Even, S., Secure off-line electronic fund transfer between nontrusting
parties. (North-Holland, Amsterdam, Netherlands, p. 57-66,
1989)(Conference: Smart Card 2000: The Future of IC Cards. Proceedings of
the IFIP WG 11.6 International Conference, Laxenburg, Austria, 19-20 Oct.
1987)

Tunstall, J.S., Electronic currency. (North-Holland, Amsterdam,
Netherlands, p. 47-8, 1989)(Conference: Smart Card 2000: The Future of IC
Cards. Proceedings of the IFIP WG 11.6 International Conference, Laxenburg,
Austria, 19-20 Oct. 1987)

Hayes, Barry, Anonymous One-Time Signatures and Flexible Untracable
Electronic
Cash, in AusCrypt '90: A Workshop on Cryptology, Secure Communication and
Computer Security, January, 1990.


U. S. Patents

W. M. Benton, Funds Transfer System using Optically Coupled, Portable
Modules,
US Pat. #4,454,414, Jun 12, 1984.
 
W. G. Bouricius and P. E. Stuckert, Method and Apparatus for Secure Message
Transmission for Use in Electronic Funds Transfer Systems, US Pat.
#4,302,810,
Nov. 24, 1981.
 
D. Chaum, "Cryptographic Identification, Financial Transaction, and
Credential
Device," US Pat #4,529,870, Jul. 16, 1985.
 
W. S. Powell, "Information Communicating Apparatus and Method," US Pat.
#4,320,387, Mar. 16, 1982.
 
P. E. Stuckert, "Personal Portable Terminal for Financial Transactions," US
Pat. #4,277,837, Jul. 7, 1981.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Mon, 16 Nov 92 15:11:38 PST
To: Peter Shipley <shipley@tfs.com>
Subject: Re: Rander box and other stuff
In-Reply-To: <9211161920.AA22901@edev0.TFS>
Message-ID: <9211162311.AA09645@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>>I heard something somewhere about hard disks with a layer of thermite
>>inside the platter.  Can you say "ferrous vapor"?
>>
>>For me the ideal cryptosystem would be a small notebook with a thermite hard
>>drive and TEMPEST shielding and no multitasking.
>>
>
>you forgot the auto self destruct if the unit is more then 4 meters from
>your person. 

If we're going to have auto self destruct with a range limit, it should also
be waterproof so I can take it swimming (and so that the self destruct
system won't be impeded by water).

And if it's going to have a four meter limit, it needs to be so light that I
can carry it absolutely everywhere, like under 500 grams, and if it's going
to be that small, it won't be able to have a keyboard (use pen input) or a
hard drive (lots of battery backed ram instead).

In fact, now that we've dropped the hard drive and the keyboard, it might as
well just be a dedicated crytosystem, make it about 10cmX10cmX1cm and give
it an ether port, an rs232 port, a pcmcia port and an rj11 port.  It's
doable and would provide the ultimate security.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Mon, 16 Nov 92 15:33:38 PST
To: Hal <74076.1041@compuserve.com>
Subject: Re: Why remailers...
In-Reply-To: <921116013001_74076.1041_DHJ41-1@CompuServe.COM>
Message-ID: <9211162333.AA10951@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Remailers are extremely important, but we also need anonymous IP bouncers.

An IP bouncer might work like this:  there would be a user, a server, and a
target.  The server and user would each have key pairs (probably a new pair
for each session), and would trade public keys.  The user would request a
port from the server, and then would issue (encrypted) commands to the
server.

These commands might include:

telnet - open a connection to the target.  The target would route its
packets to the server, and the server would encrypt them and route them to
the user.

ignore - get ready to recieve lots of random bits and perhaps pass them on to
other servers.  This is needed to help a user confuse trafic analysis.  A
side note:  it would be useful to have a standard port on all machines that
would accept the encrypted ignore command, so that packets could just be
sent off into the ether.  Users who use bouncers would want to have their
machines open up connections, issue the ignore command, and send random bits
at some random interval.

mail - act as an anonymous remailer (like the ones we already have set up).

port - provide a port that other people can telnet in to.

This type of anonymous bouncer would be helpful for everything we do with
TCP, including perhaps mail.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
Date: Mon, 16 Nov 92 20:52:02 PST
To: cypherpunks@toad.com
Subject: ECPA - PRIVACY
Message-ID: <3759.2B0852B9@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Crossposted from FidoNet PUBLIC_KEYS

from: GK Pace
to: Mike Riddle

  I just finished reading your article concerning the "laymans view"
of the ECPA.  I found it very informative, and interesting reading.
Thank you for taking the time to study this issue, and share with the
rest of us the conclusions you arrived at, upon doing so.

  I would like to comment upon some of what you've written, in hopes
of expanding upon what you have conveyed, and have quoted your article
so that those who haven't read your article will find it easier to
understand the nature of my comments.

 ========== Begin Quote ==========
 Anytime someone passes what they hope to be a private communication to
another, they expect that their fellow citizens will respect its privacy.
Not only do the customs of society enforce this expectation, statute laws
have been enacted to insure it.  Thus, everyone knows, or should know, not
to tamper with the mail.  Everyone knows, or should know, not to
electronically eavesdrop ("bug") someone else's telephone calls.  And
everyone knows, or should know, not to do likewise with computer
communications.

Alas, not everyone knows that.  If everyone did, we wouldn't need laws to
protect what ought to be our reasonable expectations of privacy.  Not too
long ago, the Congress of the United States passed PL 99-508, the Electronic
Communications Privacy Act of 1986.  In doing so, Congress was recognizing
the way technology has changed society and trying to react to that change.
 ========== End Quote ==========

  This statement kinda sums up what the discussion is all about... and
ties this subject into the provisions of the ECPA. seems like a
fitting beginning for the remainder of what I'd like to discuss.

 ========== Begin Quote ==========
What about electronic mail, or "e-mail?"  E-Mail has been the single biggest
area of misinformation about the new law.  First, section 2701 does make it
a federal offense to read someone else's electronic mail.  That would be
exceeding your authorization, since "private" e-mail systems do not intend
for anyone other than the sender or receiver to see that mail.  But, and a
big but, sysops are excluded.
 ========== End Quote ==========

  This statement in and of itself lends credibility to the position
that we have the right to read any messages passing thru our system...
however as you continue to mention, this exclusion is not without
conditions, and it isn't necessarily a "right" but is perhaps more
accurately defined as an acknowledgement of the technical aspects of
our respective systems, and the part we play in accomodating the
transfer of E-mail...

 ========== Begin Quote ==========
 Whoever staffed the bill for Congress realized that system operators were 
going to have access to information stored on their systems.
 ========== End Quote ==========

  You also of course mention reasons for which this ability might be
desired:

 ========== Begin Quote ==========
 There are practical technical reasons for this, but there are also practical 
legal reasons.  While the Act does not directly address the liability of
sysops 
for the use of their systems in illegal acts, it recognizes they might have 
some liability, and so allows them to protect themselves from illegal use.
 ========== End Quote ==========

  This statement reeks of common sense... but is there anything in the
ECPA which would indicate a "responsibility" on the part of the Sysop
to actively monitor such communications, requiring the Sysop to assume
the position of censor, police, and/or judge, over the content of
those messages passing thru ones system - or does it again acknowledge
the techical aspects, and responsibilities the Sysop might be required
to exercise in the event the Sysop were to become aware of a message
containing potentially illegal information? 

 ========== Begin Quote ==========
  Sysops are given a special responsibility to go along with this special 
privilege.  Just like a letter carrier can't give your mail to someone else, 
just like a telegraph operator can't pass your telegram to someone else, just 
like a telephone operator overhearing your call can't tell someone else what
it 
was about, so sysops are prohibited from disclosing your e-mail traffic to 
anyone, unless you (or the other party to the traffic) give them permission.
 ========== End Quote ==========

  This analysis is again just plain common sense, and again the
question arises, are the provisions this refers to those which are
acknowledged as technical limitations, accomodating them as such, or
are they to be construed as indications that we have obligations above
and beyond that which is necessary for the performance of the service
we are providing?

 ========== Begin Quote ==========
What all this has said is that the federal criminal code now protects
electronic communications the way it previously protected written ones.  It
understands that mailmen, physical or electronic, have access to the mail
they carry, so it tells them not to tell.
 ========== End Quote ==========

  This statement seems clear enough... but when viewed from the aspect
of the issue of wheather "private" E-mail should be allowed in
Fidonet, it gives rise to some questions which can possibly be best
conveyed by following the analog you have chosen... i/e that of a
mailman, and that of "paper mail".

  The issue of the Sysop having the ability to read e-mail, as
compared to the provisions of the ECPA appear to be more closely
comparable to "postcards" being carried by a mailman.  In this case,
no one could deny that the mailman has a "technical" ability to read
the postcards being carried, and that the requirements on the part of
the mailman not to divulge such information he/she might happen to
notice is clear... as are the responsibilities that would be evident
were he/she to become aware of information which could resonably be
contrued as illegal in nature.  But as in the example of the mailman
handling paper mail, there exists the ability to send "private" paper
mail, which is enclosed in an envelope.  In such cases is is not
within the rights of the mailman to open such mail to enable his
ability to determine the contents thereof, nor is there any legal
responsibility for the mailman to have knowledge of the contents
thereof.  Indeed it would be a criminal act were the mailman to do so.

  With the above in mind, wouldn't the introduction of private e-mail
capabilities in Fidonet be governed by the same logic?  And isn't
public key encryption simply the means of wrapping an envelope around
e-mail to make it private?


                               -gk

--- GenMsg vers:1.14/a
 * Origin: Privacy... everyone needs it, Lets Route it thru FidoNet (1:374/26)
SEEN-BY: 11/2 13/13 101/1 109/25 114/5 123/19 124/1 125/20 28 33 40 111 125
SEEN-BY: 125/180 1212 203/1 23 205/10 209/209 280/1 390/1 396/1
;;PATH: 374/26 12 1 151/1003 13/13 396/1 203/23 125/125 33


--  
tom jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Mon, 16 Nov 92 18:19:20 PST
To: uunet!shearson.com!pmetzger@uunet.UU.NET
Subject: The legality of PGP
In-Reply-To: <9211161902.AA08397@newsu.shearson.com>
Message-ID: <9211170057.AA11937@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


Also, every day they don't enforce the patent is silent reinforcement
to the view that their patent is illegitamate (in that it covers a
mathematical algorithm).  I doubt this has legal standing other than
as material to try to convince juries with.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hugh@domingo.teracons.com (Hugh Daniel)
Date: Mon, 16 Nov 92 19:11:21 PST
To: cypherpunks@toad.com
Subject: Idea on Random Number Generators
Message-ID: <9211170302.AA02806@domingo.teracons.com>
MIME-Version: 1.0
Content-Type: text/plain


  The problem with Diodes and the like is that it is possable to
induce a pattern into the output of these things.  Well, might we be
able to look at how and set up a counter such that if the open end is
held high on one diode it gets driven down on a second circuit which
get added togethor before we go onto to 0/1 ballencing?
  Next I would set up a drifting clock rate on the device reading the
diode, this messes up many efects of interference and might help look
for induced patterens!  Hey, imagen a random number generator that
tells you when the bad guys are trying to influence your random
numbers!
		||ugh




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Mon, 16 Nov 92 19:19:15 PST
To: hugh@toad.com
Subject: Idea on Random Number Generators
In-Reply-To: <9211170302.AA02806@domingo.teracons.com>
Message-ID: <9211170318.AA25949@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


It is very hard to generate really random numbers no matter what you do.
See the famous RAND book "One Million Random Digits with 100,000 Normal
Deviates" for their adventures trying to generate random numbers by
counting particle emissions from a radioactive source.  Even after
all kinds of statistical massaging there were still correlations in the
output.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Mon, 16 Nov 92 01:23:23 PST
To: cypherpunks@toad.com
Subject: Nuking CD's
Message-ID: <9211160914.AA29147@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


If you dont have small children about the house get a container of the
right acid so you slip your cd through the slot and 3 bubbles later it's
disintegrated.

Mark




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Mon, 16 Nov 92 21:32:47 PST
To: cypherpunks@toad.com
Subject: Re: Extortion Explosion
Message-ID: <9211170533.AA27523@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


   Cheer up, Cassandra!  Things aren't all that bad.

   > New opportunities in the extortion industry:
   > 
   > Old problem: the victim may inform the police, making it risky to pick up the
   > money, which will likely be watched.
   >      New solution: demand payment via cryptomoney.

   Many forms of electronic money can be traced if there is cooperation
   between the payer and the bank.  For example, [...]
   However, if she simply _tells_ the bank the value of C,
   then when Bob goes to deposit it, he can get caught.

Fine, if there are some forms of electronic money which can be traced
sufficiently to suppress extortion by rivals, and there are some forms
which are less traceable, will we have the wisdom to advocate the ones
which enable our main oppressor to maintain its monopoly on extorting
us?  I suspect for many on this list, it would be a bitter pill
indeed (it was for me).

   > Old problem: you may be caught firebombing the house, shooting the victim,
   > slashing the victim's daughter's face, or whatever; if you subcontract to a
   > thug, the thug may be caught and inform on you.
   >      New solution: use cryptomoney (and a reputation for paying) to hire thugs
   > while maintaining anonymity.

   Well, if thugs know that they are now going to be taking the sole
   responsibility for their actions, without the safety of knowing that
   they can rat on their employer if worse comes to worst, then they'll
   charge more to make up for the greater risk.  This will make extortion
   less profitable.

Enough to outweigh the new advantages?

   > Old problem: providing protection, so that you keep a supply of economically
   > viable victims from whom to extort.
   >      New solution: Please find one! If the government can't protect victims
   > from you, how can you protect them from competitors?

   This is the key point.  What stops protection rackets now?  Is it really
   the points listed above: that the money may be traced, that others may
   falsely benefit from my reputation, that thugs may inform on me?  What
   about simple physical surveillance of property?  What about revenge on
   the transgressors?  (As above, the revenge would be restricted to the
   thugs who did the job, but if it was bad enough it would still have a
   strong deterrent effect.)

My impression is that *the* weak link in extortion activities now is
how to pick up the money.  This is where most extorters get caught,
and it is where our monopolistic extortion & protect racket
concentrate their protection activities when faced with a competitor.
If someone has a more informed understanding of the practice of "law
enforcement authorities" when faced with competitive extortion, please
post.  Thanks.

   > Wishful thinking in the pursuit of liberty is no virtue; realism in the
   > defense of imperfect liberty is no vice. Free-lance oppression isn't freedom,
   > and I don't want it.
   > 
   > Cassandra

   It makes more sense to have good fire and police forces to deal with
   the bad guys than to get all in a tizzy because the bad guys can talk
   to each other now without getting caught.

If I believed that the police forces could still protect effectively
when deprived of their major tool (monitoring the money pickup), then
my objection would go away.  However, I don't see how they can.  It's
just too easy to firebomb a house (or any number of other attacks)
when no one's looking.

   Polyanna 

Cassandra
1784360449840245




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Mon, 16 Nov 92 21:58:10 PST
To: cypherpunks@toad.com
Subject: re: Re: Rander box and other stuff
Message-ID: <3762.2B08842B@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> In fact, now that we've dropped the hard drive and the 
 U> keyboard, it might as well just be a dedicated 
 U> crytosystem, make it about 10cmX10cmX1cm and give it an 
 U> ether port, an rs232 port, a pcmcia port and an rj11 port. 
 U>  It's doable and would provide the ultimate security. 

And if all this is a real consideration, it might be better to use a
tool that lets you use a completely non-physical key -- one you can
remember in your head.

Fit the tool to the job...

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Mon, 16 Nov 92 22:58:21 PST
To: cypherpunks@toad.com
Subject: re: November 21 meeting, 12 noon, at Cygnus offices
Message-ID: <3765.2B0896A5@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> ANNOUNCEMENT
 U> ============
 U> 
 U> The Third Physical Cypherpunks Meeting: Project Planning
 U> 
[...]
 U> 
 U> DIRECTIONS
 U> ==========
[...]
 U> 
 U>         Cygnus Support
 U>         1937 Landings Drive
 U>         Mt. View, CA  94043
 U> 
 U> There's no phone service there yet.

Wrong! 415-903-1400

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Mon, 16 Nov 92 05:12:40 PST
To: cypherpunks@toad.com
Subject: Re:  Cryptographer jailed for selling crypto to political opposition?
Message-ID: <9211161312.AA09303@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


>Chances are that Crypto AG has sufficient connexions in high places as to be
>able to get its people out of there.  I'm familiar with another case
>involving a large northern Euro maker of telecom systems who had two
>engineers taken hostage in Iraq on some inflated charge, and sentenced to 7
>years... the company fully expects to have its engineers out of there within
>six months, no question about it.    

Shades of Ross Perot.

Is it illegal to attempt to attack Iraq's computer systems if you were sitting
in your room one day and decided it was time to play havoc right back at them?

I realise the CIA etc would be involved in that sort of thing anyway but if a
private citizen decided to quietly have a dabble, and he wasnt spotted by the
Iraqi's at least, would many people get upset? There is the possibility of
encroaching on USA clandestine operations I guess...

Are there any precedents for this? Has anyone actually become aware of
attempts? :)

Mark




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Tue, 17 Nov 92 00:50:35 PST
To: hh@soda.berkeley.edu
Subject: Re: Rander box and other stuff
Message-ID: <199211170849.AA24504@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Eric (Hollander; my last post was to Eric Hughes)-

Your "small laptop with (goodies)" was EXACTLY what we were trying to go for
in 1983/84.  This was the "Cryptex CS-3" project.  Remember that there was
no such thing as a laptop at the time.  What I was proposing was a
self-contained portable encryption terminal.  It would have measured about a
foot wide by 10" long by about 2-3" thick, had an LCD for about six to eight
lines of text at a time, two 3-1/2" FDDs, a pair of sockets for "Codepacks"
(hardware key storage devices which would have been tamper-resistant and
password protected), a good quality keyboard, a modem with modular jack and
optional acoustic couplers (for payphones: low-tech anonymity)... the
Tempest feature would have been achieved by putting 100dB of white noise on
the metal housing, which would have been imperfect but decent enough.  There
was no plan for a hard drive; the operating software would have been a
simple line editor and the crypto routines, all burned into ROM and part of
the main processor board.  No plans for thermite linings at the time either,
though we did have a password routine with a duress option, which would have
erased anything on the FDDs or the Codepacks.  

My first intended market for this thing was the political dissident
community, where communication has always suffered to a small but noticeable
degree by the "we can't talk on the phone" factor.  It never got going
because the market was too small.  Now it would seem the time has definitely
come... though whatever ultimately arises out of the cypherpunk scene will
be many many times more sophisticated and versatile.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hugh@domingo.teracons.com (Hugh Daniel)
Date: Tue, 17 Nov 92 01:21:53 PST
To: cypherpunks@toad.com
Subject: Random Numbers Boxes and Cypher Processers
In-Reply-To: <3762.2B08842B@fidogate.FIDONET.ORG>
Message-ID: <9211170913.AA02943@domingo.teracons.com>
MIME-Version: 1.0
Content-Type: text/plain


  Ok folks, sounds like its time to look into the guts of Telebits and
XyZel's and see if we can make cypher-processers of them.  Both have
real CPU's and DSP's, what more do you want?
		||ugh




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Tue, 17 Nov 92 01:29:58 PST
To: hugh@toad.com
Subject: Random Numbers Boxes and Cypher Processers
In-Reply-To: <9211170913.AA02943@domingo.teracons.com>
Message-ID: <9211170929.AA07530@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


      Ok folks, sounds like its time to look into the guts of Telebits and
    XyZel's and see if we can make cypher-processers of them.  Both have
    real CPU's and DSP's, what more do you want?

Hardware devices tend to have barely enough processing power to 
do the function they were designed for---if there were some power
left over, the designers would have used a cheaper and weaker processor.

Why would you want to do encryption in your modem instead of on
the host cpu that the modem is talking to?




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: avalon@coombs.anu.edu.au (Darren Reed)
Date: Mon, 16 Nov 92 07:03:26 PST
To: cypherpunks@toad.com
Subject: AUSCRYPT '92
Message-ID: <9211161438.AA12340@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


Hmmm...after reading the announcement in alt.security it seems
quite a huge conference for ppl interested in cryptology...anyone
going ?  (Rather large number of papers being presented too!)

darren




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 17 Nov 92 03:40:49 PST
To: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Subject: The Dining Cryptographers Protocol
In-Reply-To: <9211161815.AA29148@toad.com>
Message-ID: <9211171140.AA14731@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Marc.Ringuette writes:

>My spin on the Dining Cryptographers Protocol is, it's nifty and
>theoretically strong, but in practice mixes are better for almost all
>uses.  [...]  N is typically 100-10000, and M is typically 2-10.
>Mixes are more efficient.

Let me continue to be a broken record.  Cryptography is all economics.

You want unconditional security, you pay.  Period.  Sometimes it's
worth it, sometimes it's not.  It is not up to the cryptographer to
make the economic judgement, it is up to the user.

>One advantage of DC-nets is that they're instant; with mixes there must be
>some delays in order to accumulate enough cover messages to defeat traffic
>analysis.

This idea of "delays" providing security for a mix is a common, but
incorrect, notion.  I don't think Marc is incorrect about this here,
merely unclear.  In a well used mix system, the latency time to
accumulate ten messages would be only a few minutes.

It is the reordering of the output messages with respect to the input
that provides mix security.  Any delay in merely a consequence of the
time to collect.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hugh@domingo.teracons.com (Hugh Daniel)
Date: Tue, 17 Nov 92 04:00:36 PST
To: cypherpunks@toad.com
Subject: Random Numbers Boxes and Cypher Processers
In-Reply-To: <9211170929.AA07530@napa.TELEBIT.COM>
Message-ID: <9211171151.AA03083@domingo.teracons.com>
MIME-Version: 1.0
Content-Type: text/plain


  Folks had been talking about doing some crypto things in custom
hardware about the size of a Telebit.  Telebits are just computers
with ROM's in them and since Telebits are falling behind the tide of
telecommunications I thought it might be nice to reporgram them as
remote processers.  The DSP's are quite fast and might give us very
nice random numbers, the box has buffers and a CPU that can do flat
out UUCP 'g' with compression so is likely more processer then most of
the Fido systems out there currently.
  All around a nice box sitting there wasting, waiting to do something
usefull.

  So, maybe hook up the modem with a shielded cable, cut/add something
on the phone side so one of the phone line DSP can get random garbage
(it might be much easyer then that once someone looks at the design of
the things), reporgram the ROMS to add random noise software and maybe
even do some number crunching for you (lets see a T2500 has three
DSP's in it?) for encryption/decryption.
  This is all a bit far feched, but as time goes on there will be lots
of discarded Telebits (can't do V.32bis, V.fast, FAX, Voice, DSU/CSU,
etc.).  XyZel also has a smart modem that one can blast ROM's for.
  Just something to think about on rainey days...

		||ugh




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 17 Nov 92 10:13:59 PST
To: cypherpunks@toad.com
Subject: Re: Random Numbers Boxes and Cypher Processers
Message-ID: <9211171810.AA16367@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain




Hugh Daniel writes about converting used Telebit modems for crypto
use:

>   Folks had been talking about doing some crypto things in custom
> hardware about the size of a Telebit.  Telebits are just computers
> with ROM's in them and since Telebits are falling behind the tide of
> telecommunications I thought it might be nice to reporgram them as
> remote processers.  The DSP's are quite fast and might give us very
> nice random numbers, the box has buffers and a CPU that can do flat
> out UUCP 'g' with compression so is likely more processer then most of
> the Fido systems out there currently.
>   All around a nice box sitting there wasting, waiting to do something
> usefull.

Great idea! Figuring out how to rewire and reprogram a Telebit modem
and then writing a port of PGP for it seems like a real service to the
half-dozen or so people in the world who have these Telebits and who
want what you describe.

I hope my good friend Hugh is not angered by my mocking tone!

A serious issue is economics, the allocation of scarce resources. Eric
Hughes keeps pounding on this.

A cheap RNG might be useful, but not for most people. And I can't
imagine many people trying to scrounge old Telebits so as to get good
random numbers (this assumes someone actually writes the RNG code,
tests it for statistical properties, and submits it for "breaking" by
others). 

More important is getting easy to use software out there. Modifying
relatively scarce hardware (which Telbitw are, outside our circle of
friends :-}) goes against this "populist crypto" philosophy.
Zimmerman's really important contribution was to actually get RSA out
to anyone with a PC or vanilla UNIX.

Finally, why focus on the Telebit? I have an old Processor Technology
"Sol" computer that could be similary reprogrammed for RNG use. Any
takers?


(Just kidding.)

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Tue, 17 Nov 92 08:16:02 PST
To: cypherpunks@toad.com
Subject: Re: Hackers, Crackers
Message-ID: <9211171542.AB00557@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


>Let's cut out this elitist "crackers" crap altogether.  

Well, I don't know about this guy, but there's something similar that 
occurred to me during the hackers conference.  Some of the people on this
list heard me express it badly, and I wanted to clarify.

We always used to distinguish hackers from crackers.
But cracking reveals the cracks in a way that nothing else does.  
It makes them real, sometimes laughably or painfully so.
Electronic privacy is currently a joke.  It's bad.
You need to know what kinds of attacks you're trying to defend against.
I used to think those arguments were rationalizations.  
Now I'm glad there are people who know this stuff, who are actually doing it.
Some of "them" are on what I think of as the good side, and "we" need that
kind of knowledge, if only as an occasional splash of cold water, a spur
(to switch metaphorical, er, horses in mid, um, stream).

-fnerd
quote me
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: O'Hara Walter <oharaw@jmb.ads.com>
Date: Tue, 17 Nov 92 12:20:42 PST
To: Cypherpunks <cypherpunks@toad.com>
Subject: Any suggestions on what to do with this junk?
Message-ID: <2B098C48@gallows>
MIME-Version: 1.0
Content-Type: text/plain



Hi, I'm new to this list so pardon my ignorance/naivete

I'm a systems admin type who is upgrading a bunch of desktop computers next 
month.  As a consequence, about half a dozen computers of the XT vintage 
will fall under my wing with instructions to "find something useful to do 
with them."  Are there any good suggestions out there about what I could do 
with old 8-bit technology vis-a-vis crypto?

Thanks,

Walt





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Mon, 16 Nov 92 20:01:36 PST
To: cypherpunks@toad.com
Subject: Re: IP bouncers
Message-ID: <9211170401.AA22825@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


>Remailers are extremely important, but we also need anonymous IP bouncers.
>
>An IP bouncer might work like this:  there would be a user, a server, and a
>target.  The server and user would each have key pairs (probably a new pair
>for each session), and would trade public keys.  The user would request a
>port from the server, and then would issue (encrypted) commands to the
>server.
>
>These commands might include:
>telnet - open a connection to the target.  The target would route its
>ignore - get ready to recieve lots of random bits and perhaps pass them on to
>mail - act as an anonymous remailer (like the ones we already have set up).
>port - provide a port that other people can telnet in to.
>This type of anonymous bouncer would be helpful for everything we do with

I have and use something along these lines. It was written by someone for
other purposes but it should be easy enough to port to this application.
It's rather inefficient at the moment unfortunately. I'll see what I can do
to it.

Mark




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Tue, 17 Nov 92 16:37:25 PST
To: "George A. Gleason" <gg@well.sf.ca.us>
Subject: Re: Rander box and other stuff
In-Reply-To: <199211170849.AA24504@well.sf.ca.us>
Message-ID: <9211180036.AA19273@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I thought of another thing to add to my wish list for a dedicated
cryptosystem:  analog input and output, for use as a phone line scambler.
Such a system could be manufactured for not too much money, I think.  It
would be like a specialized version of the Apple Newton.  Apple would never
make something like this, though; they are becoming good buddies with our
favorite agency.  Also you would probably need a permit to own thermite.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "erodenbeck"  <RODENBEC@newschool.edu>
Date: Tue, 17 Nov 92 15:50:34 PST
To: cypherpunks@toad.com
Subject: a patently false rumor
Message-ID: <MAILQUEUE-101.921117164749.11904@newschool.edu>
MIME-Version: 1.0
Content-Type: text/plain


all right so i got it from MONDO.
accepting that the world has already been taken over
and that if its not on tv it doesn't happen
I submit
and propose to you that it is for the taking

but of course you already know that




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Tue, 17 Nov 92 17:22:27 PST
To: eichin@cygnus.com
Subject: Rander box and other stuff
In-Reply-To: <9211180058.AA15692@tweedledumber.cygnus.com>
Message-ID: <9211180121.AA02510@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


	    Let's see -- an ISDN-quality (quality? I use the term loosely)
    codec should be under $50 single quantity, the data rate isn't very
    high so you don't need much of a CPU (6811 might even be enough, and
    they're easy to interface to things -- lots of on-chip I/O). You'd
    need a modem-style encoder for the output (running digital from
    box-to-box -- "analog" scrambling (Time or Frequency domain) is way
    too easy to break) so maybe another $50 DSP chip... after all, you
    don't need to support 30 different baud rates, just one data rate with
    perhaps a low-line-quality backoff. 

The codec is pretty cheap, but you want a nice low bit rate so you can
send the encrypted data over the phone.  Some talk of how to do this
is happening on sci.crypt.  I have a scheme which I plan to float
around at the cypherpunks meeting on Saturday.  However, the hardware
ends up being on the expensive side ($150 or so).




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Brad Huntting <huntting@glarp.com>
Date: Tue, 17 Nov 92 18:50:46 PST
To: cypherpunks@toad.com (Eric Hughes)
Subject: No Subject
In-Reply-To: <9211150654.AA20021@toad.com>
Message-ID: <199211180249.AA00524@misc.glarp.com>
MIME-Version: 1.0
Content-Type: text/plain



Please add me to the cypherpunks mailing lists.  Here are my
two public PGP keys if your interested:


brad

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQBNAir99E4AAAECALCo19KN/eLnMKicKH9NK9uY3gpaNAZ3vMPpiIAOH5sWOfxK
t0bv/T0NnUC0kGr+kJsYAx7dTGc4C/Rx3rZuO/8ABRG0JkJyYWQgSHVudHRpbmcg
PGh1bnR0aW5nLjUxMkBnbGFycC5jb20+iQBFAgUQKv32PjNoJjtQO7sNAQHQPAF/
TK1mO9Bpm0JCtxqYvCilvMEYohlDmC6pTl6XPxViil8WXOs04nkq+vy26+QCrgd4
=T+VL
-----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQA9Air9nn0AAAEBgNK6vPMg3KFzZxuB4llRoKEOxJvlO/TE0NNObgpRFs+px45+
3z4YQbgzaCY7UDu7DQAFEbQiQnJhZCBIdW50dGluZyA8aHVudHRpbmdAZ2xhcnAu
Y29tPokAVQIFECr99nML9HHetm47/wEB6OMCAK82O/iSxEK6PzUd4Y0FXvfoJRKD
F/h+6NvbIf2tt0b7IARoLL2e/fw0AaR0TY2U+47s3NBWEAL1Iy+5AV16qyc=
=cpUM
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Tue, 17 Nov 92 16:58:34 PST
To: hh@soda.berkeley.edu
Subject: re: Rander box and other stuff
In-Reply-To: <9211180036.AA19273@soda.berkeley.edu>
Message-ID: <9211180058.AA15692@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


>> Also you would probably need a permit to own thermite.
	I don't think there's a problem with owning it or making it --
only (perhaps) selling it and transporting it; thermite is not
strictly an explosive.
	You may wish to consider alternate ways of destroying the
data, especially if you wish to ever transport the device on a
commercial airline; if you've only got one RAM device that has
critical data in it, then simply arrange for the battery backup
circuit to have a "high current mode", perhaps feeding more of the
pins -- a "light emitting RAM" should be just as blank as one burned
through by thermite.

>> cryptosystem:  analog input and output, for use as a phone line scambler.
>> Such a system could be manufactured for not too much money, I think.  It
	Let's see -- an ISDN-quality (quality? I use the term loosely)
codec should be under $50 single quantity, the data rate isn't very
high so you don't need much of a CPU (6811 might even be enough, and
they're easy to interface to things -- lots of on-chip I/O). You'd
need a modem-style encoder for the output (running digital from
box-to-box -- "analog" scrambling (Time or Frequency domain) is way
too easy to break) so maybe another $50 DSP chip... after all, you
don't need to support 30 different baud rates, just one data rate with
perhaps a low-line-quality backoff. The connectors and the box are
probably the major recurring cost (the chip prices will go way down in
quantity.) Am I missing anything? The technology level of the Newton
seems to be a bit of overkill (unless you actually want that kind of
user interface.)

					_Mark_ <eichin@cygnus.com>
					<eichin@athena.mit.edu>
: note that this is an unsigned message. 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Tue, 17 Nov 92 21:27:43 PST
To: cypherpunks@toad.com
Subject: re:
Message-ID: <3790.2B09CE75@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: huntting@glarp.com (Brad Huntting)

 U> two public PGP keys if your interested:

Why did you sign your key?

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Wed, 18 Nov 92 01:03:18 PST
To: phr@napa.Telebit.COM
Subject: Re:  Random Numbers Boxes and Cypher Processers
Message-ID: <199211180900.AA05387@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Why do encryption in the modem instead of the host cpu?  Because then you
have a product which will work with any computer, and all you need is
software to make it adapt to whatever you're using.  Might make it easier to
encrypt and decrypt on the fly also, though this point is of debatable
merit.

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Judith Milhon <stjude@well.sf.ca.us>
Date: Wed, 18 Nov 92 12:04:21 PST
To: cypherpunks@toad.com
Subject: damn: sorry
Message-ID: <199211182003.AA08793@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



my column in the current issue of mONdo pointed readers to this list, rather
than -request. the final line edit didn't correct that, and the issue is now
on the stands. if there ARE any readers, they may blunder in here
cluelessly, and it's all my fault.

damn sorry.

>jude<




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Wed, 18 Nov 92 15:04:26 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Request for more detail
Message-ID: <yacguB1w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


On Nov 15, Phil Karn wrote:
 
    After reading the details of that (formerly) secret back-room
    agreement between NSA and SPA, I don't think I'll *ever* trust a
    commercial encryption package, especially one for which source
    code is unavailable for scrutiny.
 
Could Phil or anyone give more details about that agreement and/or
where one could read more about it?

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Judith Milhon <stjude@well.sf.ca.us>
Date: Wed, 18 Nov 92 13:18:24 PST
To: cypherpunks@toad.com
Subject: Re:  a patently false rumor
Message-ID: <199211182113.AA22716@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


uh oh: i gave the wrong contact info with that Irresponsible emission: it
was spozed to be cypherpunks-request@toad.com.

HOWEVER: here you are, d00d. you've landed in the midst of a multistrand
technical argument about the logistics of applied cryptography...

>jude<




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Wed, 18 Nov 92 18:07:09 PST
To: "McGrath, James" <MCGRATHJ%GRNET@lan.lincoln.cri.nz>
Subject: Re: PGP to SMTP mailer
In-Reply-To: <9211182353.AA04620@crop.lincoln.cri.nz>
Message-ID: <9211190206.AA13706@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



sounds like it might be a good idea to implement windowing support for pgp.
we could write versions for windows, xwindows, mac and possibly other
systems.  it would not be too hard to write a generic windowed pgp and then
make it specific for these systems.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wcs@anchor.ho.att.com (Bill Stewart)
Date: Wed, 18 Nov 92 19:16:30 PST
To: cypherpunks@toad.com
Subject: Re: PGP to SMTP mailer
Message-ID: <9211190308.AA25694@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text


Embedding SMTP support into a PGP mail reader is the wrong approach,
though the DOS world seems to be going bananas over mail APIs.
You gain a lot of flexibility by separating the Mail User Agent,
which handles user interface, file storage, encryption and other decoding, etc.
from the Mail Transfer Agent function, which lets you send/receive PGP
messages over whatever mail systems you have available.
That way you don't need to write one PGP program for SMTP, another for
uucp, another for Fido, etc.  

On the other hand, I'd be interested in seeing a PGP hook built into
Lotus Notes - does it have an open programming or file-transfer interface?
It seems to be multimedia netnews for the mundanes, and getting 
some flavor of Public-Key encryption out there could help spread the technology,
especially if Lotus were to license RSA support.

			Bill Stewart, somewhere in New Jersey.



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Thu, 19 Nov 92 03:54:30 PST
To: cypherpunks@toad.com
Subject: Finally back
Message-ID: <9211191150.AA16617@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Greetings,  I'm finally back on-line for a few days here,   and want
to make the most of it.   I'll be checking my Email frequently during
the day tommorrow,  and reading all back messages (All 120 of them),
getting cought up on the latest...   Before I forget,   if anyone
wants to send me an encrypted message,   My key is as follows,  so
Pse add it to your pubkey list in case you want to send me an
encrypted message.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQBNAisLBHoAAAECALXEdhLz3F9RmO6ypGFbR4/YqLgbHOrkDxVEgGMCMVQJh8zr
/75cTwvXI7dyGorWqvkvhUw1jU7BvMSvyK9YOv8ABRG0IkpvaG4gVC4gRHJhcGVy
IDxjcnVuY2hAbmV0Y29tLmNvbT4=
=rTrk
-----END PGP PUBLIC KEY BLOCK-----

I haven't really started collecting pub keys yet,   but I propose
that we have a list stored somewhere on an ftp site.   Or perhaps
someone who has the keyrings.

I'll have more things to Email later on,   it has been a long night
here,  finally got to most Email.

Had one fatal crash of the MacPGP program where it hung up the system
when I tried to encrypt a message to someone.

I have now tested out the PGP program fully,  and now know how to use
it.    I can see plenty of omprovements I will want to make,   but to 
do it right,   we might have extensive changes to make.    Still not
done looking at code yet,    but the modules I
ve seen are pretty easy to inderstand.

Later...

John D>




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 19 Nov 92 19:40:10 PST
To: cypherpunks@toad.com
Subject: Re: How far is to far?
Message-ID: <9211191822.AA06330@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain




Mark (mark@coombs.anu.edu.au) writes:

> Maybe it's not in the spirit of this mailing group but what of the question
> of purposeful abuse of the anon mailers/newsposters? Say for instance some
> person posts either a sh*tload of garbage to every known group, flooding
> the USENET or a more personal attack whereby they send out anonymously 
> information that was so fundamentally personal to someone they could
> possibly react very badly....
> 
> What if someone posted some top secret information and the various three
> letter acronyms all went out for someone's blood.

Abuses of various sorts will surely occur. The same thing happens with
the postal systems of the world ("blackmail," poison pen letters,
ransom demands, extortion threats, child pornography, sedition, etc.),
with the phone systems (ditto above), freely available Xerox machines,
and so on. Computers and computers nets will be no different.

A difference is that the authorities are trying to stop all such
abuses on computer nets and all such things they dislike by banning
privacy and by restricting use. This is a doomed effort.

> As a few people have mentioned they would *like* the opportunity to use
> an anon system but the initial step of creating and running it isnt so
> appealing due to the fundamental dangers of it.
> 
> Most people would respect such systems but you find one really rotten or
> immature loser that will use it for there own anti-social ends.

This is where "reputations" and "kill" files come to the fore.
Immature flames and other minor crimes are best dealt with by
"down-checking" the reputation of the digital pseudonym of the
offender. (Completely anonymous postings, where no "handle" or digital
pseudonym is provided are likely to be "killed" by most readers.)

For more serious "crimes" perpetrated by crypto users, well, nothing's
perfect. As I said above, they have other channels to use as well.

An advantage of the digital pseudonym nets is that these criminals
don't know who you are or where you live (a la "True Names") and hence
can't perpetrate certain crimes. 

When in cypherspace, be careful!

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: awaiting Macintosh version.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hkhenson@cup.portal.com
Date: Thu, 19 Nov 92 20:02:08 PST
To: cypherpunks@toad.com
Subject: Re: The legality of PGP
Message-ID: <9211191023.1.22089@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


Perry writes PGP is based on RSA . . . which has not granted a license
for people to use . . . . using PGP is possibly a pattent violation . . .
I wonder--I have RSA Mailsafe.  Do you think that would give me a license
to use RSA if I loaded up PGP?  Keith




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fen@genmagic.com (Fen Labalme)
Date: Thu, 19 Nov 92 19:37:21 PST
To: cypherpunks@toad.com
Subject: Re: PGP to SMTP mailer
Message-ID: <9211191957.AA18482@>
MIME-Version: 1.0
Content-Type: text/plain


[wcs@anchor.ho.att.com (Bill Stewart) writes:]

>On the other hand, I'd be interested in seeing a PGP hook built into
>Lotus Notes .... if Lotus were to license RSA support.

I believe that Lotus has licensed RSA technology for notes.

Fen
~~~
~~~
Fen Labalme               General Magic              We Are Everywhere
40 Carl Street #4         2465 Latham Street        -------------------
San Francisco CA 94117    Mountain View CA 94040    The US Constitution
415/731-1174 (home)       415/966-6273 (my desk)    may not be perfect,
<fen@netcom.com>          415/965-9424 (fax)        but it's better than
<fen@well.sf.ca.us>       <fen@genmagic.com>        what we've got now.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fen@genmagic.com (Fen Labalme) (by way of fen@genmagic (Fen Labalme))
Date: Thu, 19 Nov 92 19:37:21 PST
To: cypherpunks@toad.com
Subject: Re: Anymous Remailers and Newsposters
Message-ID: <9211191959.AA18490@>
MIME-Version: 1.0
Content-Type: text/plain



[VANGUARD@gribb.hsr.n0 writes:]

>I have been aware of the need to make anonymous postings on the
>newsnet. I have made most of the neseccery softwar to allow for such
>a gateway, but it seems that the local system administartor is
>strongly opposed to the idea of the protection given by beeing
>anonymous. Such a gateway has an enourmous potential, and it is easy
>to see why some wouldn't like the idea.

I just thought I'd mention that there are several anonymous remailers
currently in use by users of the alt.sex.bondage newsgroup.  Unfortunately,
I don't have the addresses handy, but they re-post the address and
instructions for use every week or so...

Fen
~~~
~~~
Fen Labalme               General Magic              We Are Everywhere
40 Carl Street #4         2465 Latham Street        -------------------
San Francisco CA 94117    Mountain View CA 94040    The US Constitution
415/731-1174 (home)       415/966-6273 (my desk)    may not be perfect,
<fen@netcom.com>          415/965-9424 (fax)        but it's better than
<fen@well.sf.ca.us>       <fen@genmagic.com>        what we've got now.







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fen@genmagic.com (Fen Labalme) (by way of fen@genmagic (Fen Labalme))
Date: Thu, 19 Nov 92 19:38:52 PST
To: cypherpunks@toad.com
Subject: Re: How far is to far?
Message-ID: <9211191959.AA18495@>
MIME-Version: 1.0
Content-Type: text/plain



[mark@coombs.anu.edu.au writes:]

>Maybe it's not in the spirit of this mailing group but what of the question
>of purposeful abuse of the anon mailers/newsposters? Say for instance some
>person posts either a sh*tload of garbage to every known group, flooding
>the USENET or a more personal attack whereby they send out anonymously 
>information that was so fundamentally personal to someone they could
>possibly react very badly....

I see two answers: one is public censure, which has appeared to work to a
large extent in at least one newsgroup whose users make habitual use of an
anonymous remailer (alt.sex.bondage) .

Another is broadcatch, a favorite topic of mine, which is concerned with
the filtering of information.  (Note:  where "broadcast" is a
one-source-to-many
subscriber system, "broadcatch" scans many sources for information relevant
to one subscriber.  The end result is less quantity and higher quality.) 
With broadcatch, you could turn off threads of conversation you were not
interested in, block out flamers, and IGNORE ANONYMOUS EMAIL in general. 
Of course, pseudonyms may come to be trusted and thus not filtered out,
though they, too, are cryptographically anonymous.  (Another common
mechanism of broadcatch filters is to allow through articles with mentions
of the subscriber's name.)

Also, in the long run, when networks are made up of smarter, cooperating
machines, neighboring machines to a flamer that is generating mass ammounts
of email will begin to choose not to listen as often at that address.

In sum, I think that it is someone's right to say anything they want, as
long as I don't have to listen.

Fen
~~~
~~~
Fen Labalme               General Magic              We Are Everywhere
40 Carl Street #4         2465 Latham Street        -------------------
San Francisco CA 94117    Mountain View CA 94040    The US Constitution
415/731-1174 (home)       415/966-6273 (my desk)    may not be perfect,
<fen@netcom.com>          415/965-9424 (fax)        but it's better than
<fen@well.sf.ca.us>       <fen@genmagic.com>        what we've got now.







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "McGrath, James" <MCGRATHJ%GRNET@lan.lincoln.cri.nz>
Date: Wed, 18 Nov 92 15:54:04 PST
To: cypherpunks@toad.com
Subject: PGP to SMTP mailer
Message-ID: <9211182353.AA04620@crop.lincoln.cri.nz>
MIME-Version: 1.0
Content-Type: text/plain


Gudday,

People were suggesting that someone write a mailer with PGP
support, and because my site uses lots of PCs connected to an
internet host, I was thinking of using an SMTP-client based
system. That much I think I can do.

However, I am also now trying to learn to program for Windows,
and the idea of a windows based PGP is quite nice, and with an
integrated mailer it would be great.

Is anyone else working on either of these two things?

What are the implications (security wise) of using something    
like windows where tasks aren't really that hidden from each
other and that swaps to disk?

I notice that PGP bothers to erase its stacks and work areas. It
seems that this would be a lot less possible under windows. 

Comments?

Jim McGrath








From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: VANGUARD@gribb.hsr.no
Date: Thu, 19 Nov 92 04:57:31 PST
To: cypherpunks@toad.com
Subject: Anymous Remailers and Newsposters
Message-ID: <MAILQUEUE-101.921119135912.480@gribb.hsr.no>
MIME-Version: 1.0
Content-Type: text/plain


    I have tried out the anonymous reply service at
hal@alumni.caltech.com and I am very satisfied with the service,
however I have a suggestion that will improve the security. The way
it works now it is possible to link different messages that have the
same originator, simply by comparing the return adress.

Example I have a deal going with Bob and a different deal going with
Alice, and it would be of my interest that Alice and Bob didnt know
they where dealing with the same person. If a had given the the same
Anonymous reply adress they could compare them and see that in fact
they were dealing with the same person, thereby making it easier to
trace me:

Solutions: Use different remailers that have different public keys,
or allow for a field of "random" i.e. different bytes so that if the
return adress is identical the encoded block would be totally
different.

I have been aware of the need to make anonymous postings on the
newsnet. I have made most of the neseccery softwar to allow for such
a gateway, but it seems that the local system administartor is
strongly opposed to the idea of the protection given by beeing
anonymous. Such a gateway has an enourmous potential, and it is easy
to see why some wouldn't like the idea.

I have also been thinking about up such a gateway in my own name (i.e
the anonymous postings would appear to come from me, with some sort
of disclaimer) but I have so far been reluctant to take the risk of
beeing identified with things that are none of my business.

Any comments and suggestions would be appreciated.











From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: VANGUARD@gribb.hsr.no
Date: Thu, 19 Nov 92 05:24:18 PST
To: cypherpunks@toad.com
Subject: Re: Anonymous Reply...
Message-ID: <MAILQUEUE-101.921119142500.352@gribb.hsr.no>
MIME-Version: 1.0
Content-Type: text/plain


    Well after I made my last posting I realized there is a mush
better way to avoid having identical reply adresses: Simply let pgp
make a new encryption of the return adress. This works because pgp
uses a different key for each message, and the key is the only
information that is encrypted with th RSA algorithm. In other words
if you encrypt a message once with a key and encrypt the same message
again with the same key, the resulting ciphertext will be totally
different, with exeption of the first bytes and the length of the
text.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "McGrath, James" <MCGRATHJ%GRNET@lan.lincoln.cri.nz>
Date: Wed, 18 Nov 92 17:36:04 PST
To: cypherpunks@toad.com
Subject: PGP to SMTP mailer
Message-ID: <9211190135.AA04790@crop.lincoln.cri.nz>
MIME-Version: 1.0
Content-Type: text/plain


Gudday,

People were suggesting that someone write a mailer with PGP
support, and because my site uses lots of PCs connected to an
internet host, I was thinking of using an SMTP-client based
system. That much I think I can do.

However, I am also now trying to learn to program for Windows,
and the idea of a windows based PGP is quite nice, and with an
integrated mailer it would be great.

Is anyone else working on either of these two things?

What are the implications (security wise) of using something    
like windows where tasks aren't really that hidden from each
other and that swaps to disk?

I notice that PGP bothers to erase its stacks and work areas. It
seems that this would be a lot less possible under windows. 

Comments?

Jim McGrath




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Thu, 19 Nov 92 19:33:56 PST
To: cypherpunks@toad.com
Subject: Some proposals to consider
Message-ID: <9211200059.AA27380@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Greetings fellow cypherpunks:

   A lot has happened since I got on here last Friday.   My previous
message contains my public key,   Pse use it if you want to send me 
private mail.

   I bet the NSA boys are tearing the hair out of their heads by
now,   but it's about time we do something to preserve our privacy.

   It is my plan to help "organize" the Mac implementation of PGP,
by putting together a Mac Implementation team of programmers to 
beef up MacPGP,  by added better GUI,  such as cutting and pasting
of keys DIRECTLY into key rings without having to go through a
file (makes for added security).

   My plans also call for tight coordination with the other platform
development teams.   

   I've been getting good support for my ideas on implementing machine
independent modules or "Libraries" of PGP routines that don't include
I/O portions,   but after looking at the code,   I see this is going to
take a lot of work,   both in organizing the effort,   and in implementing
the code.    Just how this is going to be done,  I'm not sure,   but this
is what cypherpunks is all about.    To hash these things over,  flame on
each other's ideas,  etc.

   So far,  the Mac inplementaion team consists of the following individuals,
and are (or soon will be) working closly with Eric Hughs,  Phil Zimmerman,
and the other PGP folks

Mac PGP team:

  Richard Outerbridge [71755.204]
  Jim Clausing internet: jac@cis.ohio-state.edu
  Zbigniew Fiedorowicz internet: fiedorow@function.mps.ohio-state.edu
  INTERNET:crunch@netcom.com INTERNET:crunch@netcom.com
  Doug McNaught internet: doug@midget.towson.edu
  Philip Zimmermann internet: prz@sage.cgd.ucar.edu
  
  I talked with another individual last evening who also wants to be added
to the team,   but the others haven't yet been introduced to him yet.

  It is my plan to propose this idea to the PGP meeting at Sygnus this
upcoming Saturday at noon.   Then,   I'll report to those that couldn't
make it,  due to their location.    

  The progress on the Rander box is as follows:    I am currently evaluating
several proposed designs,  and have sent out queries for data sheets on
devices I plan on checking out for use,  prices,  etc.

  I have been studying the PGP code,   and can see it's going to take a
lot of work to get it into a form where true machine portability can
be realized.   As  a Mac purist,  a abhore the idea if translating Mac
GUI actions into ascii text and sending it to the current PGP "engine".

  Although it would take a lot of work,   I propose that we develop PGP
to have the following form.

  a) Encryption engine library - Main set of routines currently in the
     PGP program dealing with encryption of data.   These would be
     a set of "support" routines that would permit encryption of
     data in files,  as well as data in memory.   These would be
     totally machine independent,  and only ONE set of sources should
     exist and contain compiler options for platform specific code.
     These functions would then return error codes instead of console
     output.   Needed "key phrases" can be passed in as "char *",
     and sucessful operations would return NULL or if error,  an
     appropriate code be returned.  Other routines would be necessary,
     such as telling it where the random ring buffer is located,  and
     how long it is.   These routines would maintain their own
     pointers into this buffer.   This library would call routines
     in the Random number manager and pass information such as where
     the buffer is located.   See below:
     
  b) Key management library - Main set of routines that know how to 
     manage the keyring files,  it would have functions designed to
     extract keys,  add and remove them,  and work on the keyring
     files directly.   Again,  these would be machine independent
     routines.   This would also call routines in the Random number
     manager below.
     
  c) Random number management - Main set of routines to manage a
     "circular buffer" of random numbers used to generate keys.  This
     would work with both software and hardware random number generators,
     and would provide externally machine independent functions,  but
     internally they would be machine specific.
     
  d) GUI's for the various PGP application programs.   Mail management,
     file management,  network applications,  etc,  all calling the
     routines in a,b, and  c.   Also includes Hypercard Xcmds,  etc.
     
  Items a and b should have only ONE set of source code,  and be 
maintained and managed by existing people.    Items c would also
be same source code,   but have conditional compiler statements 
to "switch in" the machine dependent portions as apppropriate.

  I think it's possible to design the code in a and b to have very few
machine dependent conditional compiler #ifdef statements,  by forming
the main PGP guts portion to operate on textual input in the form
of "char *" instead of console input,  and let the calling code
pass "char *" to PGP library routines.

  Machine dependent stuff is in (d) and might include existing UNIX
PGP "main()",  Mac PGP main application,  and lower level "utilities"
such as Hypercar XCMD's etc.    In fact,  it is even possible to 
build these libraries to use NO global variables,  and use structures
instead.    But me,  being Mac biased,  will probably get a lot of
resistance to this proposal,  but it is just that,  a PROPOSAL.

  At any rate,   I think that portability issues would be better solved
if we were to adopt C code portability and to assume that not ALL
platforms work well with console type input,  and that Console
I/O should be "factored out" of the machine independent portions of the
existing PGP code.

  So,  what way folks,  has anyone got a better idea or proposal?
  
Cheers
JD




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wmo@rebma.rebma.mn.org (Bill O'Hanlon)
Date: Thu, 19 Nov 92 19:43:57 PST
To: cypherpunks@toad.com
Subject: Another remailer
Message-ID: <m0msP7R-0006QgC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


I've installed Eric's anonymous remailer scripts at remailer@rebma.mn.org.
Rebma is my home machine...  It's not right on the Internet, but it is a
Telebit connection away.  Feel free to use it as you see fit.  I don't
have Hal's PGP additions, but I am interested in running them.

Hal's messages said he hoped more people put up remailers so that they could be
chained together.  Sounded good to me.

-Bill
-- 
Bill O'Hanlon						 wmo@rebma.mn.org




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Thu, 19 Nov 92 22:54:40 PST
To: fen@genmagic.com
Subject: Re: PGP to SMTP mailer
Message-ID: <9211200654.AA27391@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


Those of us who support the freedom to use cryptography, run PGP, and
write whatever programs we wish (cryptographic and otherwise) should
be aware that the boycott against Lotus and Apple is still on.  By
making PGP run on Macintoshes and with Lotus Notes, we improve the
usefulness of those systems and thereby help our enemies take away our
rights.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Thu, 19 Nov 92 04:30:00 PST
To: cypherpunks@toad.com
Subject: IP Bouncer.. source included.
Message-ID: <9211191229.AA12629@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain



Ok an IP bouncer is something that runs on a host that basically accepts
connections on one port and redirects them to another specified host and port.
The one below is for tcp connections but it could also be for udp with
a little work. I actually have the code for a 'server' version of this that
you connect to it, tell it which host you want and then it opens a 
connection to it. It's on another machine at the moment which is down.


I had the sent to me via IRC a while ago and have used it off and on. Ive
been meaning to fine tune it a bit as it's supposed to chew CPU a bit...

-------cut here--------cut here--------cut here---------cut here-------------
/* This file is telserv.c and is part of the Telnet Server package v. 1.0,
   written by "Hal-9000".  Much of this package was developed by Richard
   Stephens and my thanks go to "Xanadude" for providing me with that
   section.

   To compile, type "cc -O -s telserv.c -o telserv". */

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <fcntl.h>
#include <errno.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define SERV_TCP_PORT 12345 /* port I'll listen for connections on */
#define REM_HOST_ADDR "128.128.128.7" /* host I will bounce to */
#define REM_TCP_PORT 23               /* port I will bounce to */

main()
{
  int sockfd, newsockfd, clilen, childpid;
  struct sockaddr_in  cli_addr, serv_addr;
  sockfd = socket(AF_INET, SOCK_STREAM, 0);
  bzero((char *) &serv_addr, sizeof(serv_addr));
  serv_addr.sin_family      = AF_INET;
  serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
  serv_addr.sin_port        = htons(SERV_TCP_PORT);
  bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
  listen(sockfd, 5);
  while (1) {
    clilen = sizeof(cli_addr);
    newsockfd=accept(sockfd, (struct sockaddr *) &cli_addr, &clilen);
    fcntl(newsockfd,F_SETFL,O_NDELAY);
    childpid = fork();
    if (childpid == 0) {         /* child process */
      close(sockfd);             /* close original socket */
      telcli(newsockfd);         /* process the request */
      exit(0);
    }

    close(newsockfd);            /* parent process */
    wait(0);
    }
  }

telcli(clisockfd)
{
  int servsockfd;
  struct sockaddr_in  serv_addr;
  bzero((char *) &serv_addr, sizeof(serv_addr));
  serv_addr.sin_family       = AF_INET;
  serv_addr.sin_addr.s_addr  = inet_addr(REM_HOST_ADDR);
  serv_addr.sin_port         = htons(REM_TCP_PORT);
  servsockfd = socket(AF_INET, SOCK_STREAM, 0);
  connect(servsockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
  fcntl(servsockfd,F_SETFL,O_NDELAY);
  communicate(servsockfd,clisockfd);
  close(servsockfd);
  exit(0);
}

communicate(servsockfd,clisockfd)  {
   char rec[1];
   int num;
   extern int errno;
   while (1) {
     num=read(servsockfd,rec,1);
	 if ((num==-1) && (errno != EWOULDBLOCK)) return;
	 if (num==0) return;
     if (num==1) write(clisockfd,rec,1);
     num=read(clisockfd,rec,1);
	 if ((num==-1) && (errno != EWOULDBLOCK)) return;
	 if (num==0) return;
	 if (num==1) write(servsockfd,rec,1);
     }
}




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tenney@netcom.com (Glenn S. Tenney)
Date: Thu, 19 Nov 92 23:49:58 PST
To: phr@napa.Telebit.COM (Paul Rubin)
Subject: Re: PGP to SMTP mailer
In-Reply-To: <9211200654.AA27391@napa.TELEBIT.COM>
Message-ID: <9211200744.AA28178@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


phr@napa.Telebit.COM says:
> 
> Those of us who support the freedom to use cryptography, run PGP, and
> write whatever programs we wish (cryptographic and otherwise) should
> be aware that the boycott against Lotus and Apple is still on.  By
> making PGP run on Macintoshes and with Lotus Notes, we improve the
> usefulness of those systems and thereby help our enemies take away our
> rights.
> 

Oh give me a break!  I don't see YOU boycotting the Hayes modem
standard (AT).  Enough of this boycott crap!

-- 
Glenn Tenney
voice: (415) 574-3420      fax: (415) 574-0546
tenney@netcom.com          Ham radio: AA6ER




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 20 Nov 92 00:29:17 PST
To: fen@genmagic.com
Subject: Re: How far is to far?
Message-ID: <199211200828.AA03551@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Re. Fen's proposal to utilise "broadcatch."  We still have the problems of
slander/libel and breaches of legitimate secrecy.  

At risk of sounding naive/idealistic, it would seem that since there is no
way to block information passing through the net (aside from screening at
source, impractical at least!), the solution rests with education of the
net-using population.  Power carries responsibility in equal measure.  We
are giving ourselves the power which comes with privacy; we can begin to
take responsibility for promoting a sense of ethics in the use of the net.
One possible place to start would be at highschool-level computer courses;
perhaps with accomplished hackers coming in and giving guest lectures or
something... the culture of computer-literate youth can begin to include
strong ethical positions regarding respect for the privacy of others,
respect for truthfulness, and a position of personal conscience regarding
law and authority.  Re the latter, this isn't the same thing as blind
obedience, but rather the idea that if there is to be disobedience it needs
to be grounded in deeply held personal ethics, as for example in the case of
civil disobedience.  A strong set of cultural values in these areas might
set a tone which discourages mindless negativity and wrecking.  Now there
will always be those who wreck for thrills.... I don't know how to address
that problem except to note that such individuals are hardly stopped today
by the threat of prosecution.  

-gg@well.sf.ca.us




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Thu, 19 Nov 92 05:43:04 PST
To: cypherpunks@toad.com
Subject: How far is to far?
Message-ID: <9211191342.AA18149@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


Maybe it's not in the spirit of this mailing group but what of the question
of purposeful abuse of the anon mailers/newsposters? Say for instance some
person posts either a sh*tload of garbage to every known group, flooding
the USENET or a more personal attack whereby they send out anonymously 
information that was so fundamentally personal to someone they could
possibly react very badly....

What if someone posted some top secret information and the various three
letter acronyms all went out for someone's blood.

As a few people have mentioned they would *like* the opportunity to use
an anon system but the initial step of creating and running it isnt so
appealing due to the fundamental dangers of it.

Most people would respect such systems but you find one really rotten or
immature loser that will use it for there own anti-social ends.

Comments?

Mark
mark@coombs.anu.edu.au
mark@gnu.ai.mit.edu
markm@rmit.edu.au




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Fri, 20 Nov 92 01:01:11 PST
To: cypherpunks@toad.com
Subject: Lots of work to do.
Message-ID: <9211200857.AA02944@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain




I said earlier:

>>   I've been getting good support for my ideas on implementing machine
>>independent modules or "Libraries" of PGP routines that don't include
>>I/O portions,   but after looking at the code,   I see this is going to
>>take a lot of work,   both in organizing the effort,   and in implementing
>>the code.    Just how this is going to be done,  I'm not sure,   but this
>>is what cypherpunks is all about.    To hash these things over,  flame on
>>each other's ideas,  etc.

Miron says:

>It would be very nice if PGP behaved better as a UNIX filter.  For
>example, I'd like it to return an exit code if it fails.  I'd
>also like it to have a flag that disables any access to the tty
>for prompts.  For example, if I have an automatic  filter that
>tries to decrypt all incoming messages, I don't want it to prompt
>for a secret ring file when it can't decrypt something.

I say the folliwing:

The UNIX filter can certainly be written,   but it should use the
"services" of the PGP library code,  which might have functions 
specifically for use with UNIX,  But may not be called by Mac API's.
It's important for me to point out that these PGP routines as C
functions should be implemented as "Agents" or "Engines" and be
totally self contained and not be depending on UNIX, MacOS or other
facilities.   It is fair for UNIX programs to CALL them,   but the
PGP should not depend on UNIX,  or Machine dependent facilities other
than File IO.

Paul Rubin writes:

>Those of us who support the freedom to use cryptography, run PGP, and
>write whatever programs we wish (cryptographic and otherwise) should
>be aware that the boycott against Lotus and Apple is still on.  By
>making PGP run on Macintoshes and with Lotus Notes, we improve the
>usefulness of those systems and thereby help our enemies take away our
>rights.

I say --- Great!!  but I have invested a lot of my own finances into
purchasing my Mac II (Probably long before the boycott),  and I certainly
want to put it to good use.   This includes my rights to privacy and to
use PGP.   I don't like Apple's policy,  and think it sucks,  especially
if they dump hundreds of Mac programmers on the job marketplace,   but
sure don't want to ditch my Mac just because a few Apple FAT CATS made
bad decisions.   

David Clunie writes:

>2. A preliminary perusal of the code makes it obvious that extracting the
>   functionality from the interface is not an easy task.

I agree,  this isn't going to be easy,   SW development is NEVER easy,
so who is afraid of a little work?  With all those unemployed programmers
out there,  we should be able to get PLENTY of help!

JD




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Thu, 19 Nov 92 21:09:14 PST
To: cypherpunks@toad.com
Subject: Re: Some proposals to consider
In-Reply-To: <9211200059.AA27380@netcom2.netcom.com>
Message-ID: <1992Nov20.045112.2129@extropia.wimsey.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain


crunch@netcom.com (John Draper) writes:

>Greetings fellow cypherpunks:

>   I've been getting good support for my ideas on implementing machine
>independent modules or "Libraries" of PGP routines that don't include
>I/O portions,   but after looking at the code,   I see this is going to
>take a lot of work,   both in organizing the effort,   and in implementing
>the code.    Just how this is going to be done,  I'm not sure,   but this
>is what cypherpunks is all about.    To hash these things over,  flame on
>each other's ideas,  etc.

It would be very nice if PGP behaved better as a UNIX filter.  For
example, I'd like it to return an exit code if it fails.  I'd
also like it to have a flag that disables any access to the tty
for prompts.  For example, if I have an automatic  filter that
tries to decrypt all incoming messages, I don't want it to prompt
for a secret ring file when it can't decrypt something.

A very important addition to PGP would be multi-recipient encryption.
RIPEM implements this nicely, by having one private key (PGP has this
too - it uses IDEA) and encrypting this key with each recipient's key.

We could then run this list encrypted, in order to excercise PGP
and to see what user interface issues become important with heavy use.
(Not much security is afforded because of the public nature of the
list.)
-- 
	Miron Cuperman <miron@extropia.wimsey.com>   | NeXTmail/mime ok
		       <miron@cs.sfu.ca>	     | Public key avail
	AMIX: MCuperman				     |
immortalcybercomputinglaissezfaire		     |




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Fri, 20 Nov 92 14:19:20 PST
To: cypherpunks@toad.com
Subject: "Young Men's Crypto Association," (YMCA)
In-Reply-To: <199211200828.AA03551@well.sf.ca.us>
Message-ID: <9211201741.AA11668@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



"Young Men's Crypto Association" (YMCA)

George Gleason raises some interesting points about teaching ethics
and morality to nascent hackers, in the hope of heading off some of
the darker aspects of anonymous remailers, digital pseudonyms, and the
like:

> At risk of sounding naive/idealistic, it would seem that since there is no
> way to block information passing through the net (aside from screening at
> source, impractical at least!), the solution rests with education of the
> net-using population.  Power carries responsibility in equal measure.  We
> are giving ourselves the power which comes with privacy; we can begin to
> take responsibility for promoting a sense of ethics in the use of the net.
> One possible place to start would be at highschool-level computer courses;
> perhaps with accomplished hackers coming in and giving guest lectures or
> something... the culture of computer-literate youth can begin to include
> strong ethical positions regarding respect for the privacy of others,
> respect for truthfulness, and a position of personal conscience regarding
> law and authority.  Re the latter, this isn't the same thing as blind

I doubt this'll work. You're welcome to try, though. 

We had this same discussion in a nanotech group I attend (Ted
Kaehler's "Assembler Multitude," in Palo Alto), where the concern was
about the "grey goo" that could result from replicator development.
Several folks recommended that the best approach to handling malicious
"nanotech hacking" is _education_, just as George is recommending for
what might be called "malicious crypto."

The problems are:

1. Moral education (= Christian, in the West) has been tried for
centuries, with little apparent effect on murders, rapes, war, and
pillage. I won't knock religion here, but the teachings don't seem to
have much of an effect.

2. There's usually some fringe, which may be 10% or which may be 1%,
which does the _opposite_ of the mainstream teachings. For example,
let us suppose George successfully organizes the "Young Men's Crypto
Association," or YMCA, to go out to high schools and shopping malls to
preach the virtues of crypto temperance, of the evils of computer
viruses (a parallel to the crypto stuff talked about here, and an even
better example of "hacker morality"), etc.

This YMCA will perhaps teach some set of values to perhaps 90% or even
99% of the hacker community it preaches to. But what of the rest? A
case can be made that such preaching will _energize_ this minority
into action, if only to poke a stick into the eye of society.

3. Practically speaking, how can a handful of we crypto enthusiasts
even begin to compete with the teachings of other moralists and
religious types? We've got other fish to fry.

4. Finally, many of the "crypto anarchy" views I've been espousing for
several years now have been seen by some as grossly immoral and
dangerous. Should the YMCA (the Young Men's Crypto Association,
remember) argue _against_ such ideas? 


> obedience, but rather the idea that if there is to be disobedience it needs
> to be grounded in deeply held personal ethics, as for example in the case of
> civil disobedience.  A strong set of cultural values in these areas might
> set a tone which discourages mindless negativity and wrecking.  Now there
> will always be those who wreck for thrills.... I don't know how to address
> that problem except to note that such individuals are hardly stopped today
> by the threat of prosecution.  

I agree with George that some will always "wreck for thrills." What
crypto and privacy techniques do is give us some protection against
these vandals. Like locks on doors, or sealed envelopes, these
techniques protect us a lot better than moral lectures against
thievery or fraud.

Having said all this, if George decides to go ahead with his version
of the YMCA, maybe I'll even stand outside in the cold and ring a bell.

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 20 Nov 92 14:18:40 PST
To: cypherpunks@toad.com
Subject: The Cypherpunks Mail Project
Message-ID: <9211201830.AA29311@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



The time is now arrived for a more concerted effort to deploy
encryption.

It has become clear from the discussions on the list here that the
first step should be encrypted e-mail.  Unfortunately, mail is not
homogeneous; there is no one place to push on the mail system to add
encryption.  Thus, regardless of the method used for encryption, we
will need to add support to every single mail user agent.

I now call for this work to begin.

We will begin with the first step: a survey of existing mail agents.
I volunteer to conduct the survey.  I want to collect the following
information from _everybody_ on the list:

1.  What mail agent(s) do you use to read your everyday mail?

2.  What platforms, hardware and software, do you use it on?

Reply to hughes@soda.berkeley.edu as soon as you read this message.
It only takes a minute to tell me how you read mail.

Eric





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 20 Nov 92 14:18:20 PST
To: cypherpunks@toad.com
Subject: The Cypherpunks Mail Project
Message-ID: <9211201843.AA29819@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Step Two in the Mail Project is to gather together the social facts of
mail software development: where the source code is and who maintains
it.

Participation in this step is not required, but a distributed effort
to find this information would be greatly appreciated.

Therefore, if you know where to find source code for your own (or any
other) mail reader, please send it along.  Be complete.  Include at
least the following information:

1.  The name of the mail agent.
2.  The current version number.
3.  A machine name where the code is located, presumably via anonymous ftp.
4.  The directory on the machine where it can be found.
5.  The author(s) and maintainer(s) of the software.
6.  The licensing status of the software:  public domain, Gnuware, 
  university property but publicly usable, etc.
7.  Any useful political information about convincing whoever to support
  encryption.

If your mail agent is commercial, then send the name of the
manufacturer and any other information you can think of.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: avalon@coombs.anu.edu.au (Darren Reed)
Date: Thu, 19 Nov 92 19:35:05 PST
To: mark@coombs.anu.edu.au (Mark)
Subject: Re: How far is to far?
In-Reply-To: <9211191342.AA18149@coombs.anu.edu.au>
Message-ID: <9211192343.AA27930@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain



I've fixed the IP bouncer so it doesnt chew so much cpu any more,
backgrounds itself and detachs from the tty.  In testing last night,
it was using less %cpu than the telnet being used to connect to it on
the same machine (hope that bodes well! :).

Darren

-----------------------------------------------------------------------------
/* This file is telserv.c and is part of the Telnet Server package v. 1.0,
   written by "Hal-9000".  Much of this package was developed by Richard
   Stephens and my thanks go to "Xanadude" for providing me with that
   section.  Performance fix by Darren Reed.

   To compile, type "cc -O -s telserv.c -o telserv". */

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <fcntl.h>
#include <errno.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/ioctl.h>

#define	SERV_TCP_PORT	12345	/* port I'll listen for connections on */
#define	REM_HOST_ADDR	"127.0.0.1"	/* host I will bounce to */
#define	REM_TCP_PORT	19		/* port I will bounce to */

char sbuf[2048], cbuf[2048];

main()
{
  int sockfd, newsockfd, clilen, childpid, opt = 1;
  struct sockaddr_in  cli_addr, serv_addr;

  sockfd = socket(AF_INET, SOCK_STREAM, 0);
  setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
  bzero((char *) &serv_addr, sizeof(serv_addr));
  serv_addr.sin_family      = AF_INET;
  serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
  serv_addr.sin_port        = htons(SERV_TCP_PORT);
  if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) == -1) {
    perror("bind");
    exit(-1);
  }
  listen(sockfd, 5);
  setpgrp(getpid(), 0);
  close(0); close(1); close(2);
#ifdef TIOCNOTTY
  if ((newsockfd = open("/dev/tty", O_RDWR)) >= 0) {
    ioctl(newsockfd, TIOCNOTTY, (char *)0);
    close(newsockfd);
  }
#endif
  if (fork())
    exit(0);
  while (1) {
    clilen = sizeof(cli_addr);
    newsockfd=accept(sockfd, (struct sockaddr *) &cli_addr, &clilen);
    if (newsockfd == -1)
      exit(-1);
    setsockopt(newsockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
    /*
    ** NB: FNDELAY and O_NDELAY aren't the same on all machines and on most
    ** we want FNDELAY.  The differences are subtle but differences all the
    ** same.
    */
#ifdef FNDELAY
    fcntl(newsockfd,F_SETFL,fcntl(newsockfd,F_GETFL,0)|FNDELAY);
#else
    fcntl(newsockfd,F_SETFL,O_NDELAY);
#endif
    childpid = fork();
    if (childpid == 0) {         /* child process */
      close(sockfd);             /* close original socket */
      telcli(newsockfd);         /* process the request */
      exit(0);
    }

    close(newsockfd);            /* parent process */
    wait(0);
    }
  }

telcli(clisockfd)
{
  int servsockfd;
  struct sockaddr_in  serv_addr;

  bzero((char *) &serv_addr, sizeof(serv_addr));
  serv_addr.sin_family       = AF_INET;
  serv_addr.sin_addr.s_addr  = inet_addr(REM_HOST_ADDR);
  serv_addr.sin_port         = htons(REM_TCP_PORT);
  servsockfd = socket(AF_INET, SOCK_STREAM, 0);
  connect(servsockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
#ifdef FNDELAY
  fcntl(servsockfd,F_SETFL,fcntl(clisockfd,F_GETFL,0)|FNDELAY);
#else
  fcntl(servsockfd,F_SETFL,O_NDELAY);
#endif
  communicate(servsockfd,clisockfd);
  close(servsockfd);
  exit(0);
}

communicate(sfd,cfd)  {
  char *chead, *ctail, *shead, *stail;
  int num, nfd, spos, cpos;
  extern int errno;
  fd_set rd, wr;

  chead = ctail = cbuf;
  cpos = 0;
  shead = stail = sbuf;
  spos = 0;

  while (1) {
    FD_ZERO(&rd);
    FD_ZERO(&wr);

    if (spos < sizeof(sbuf)-1)
      FD_SET(sfd, &rd);
    if (ctail > chead)
      FD_SET(sfd, &wr);
    if (cpos < sizeof(cbuf)-1)
      FD_SET(cfd, &rd);
    if (stail > shead)
      FD_SET(cfd, &wr);
    nfd = select(256, &rd, &wr, 0, 0);
    if (nfd <= 0)
      continue;

    if (FD_ISSET(sfd, &rd)) {
      num=read(sfd,stail,sizeof(sbuf)-spos);
      if ((num==-1) && (errno != EWOULDBLOCK)) return;
      if (num==0) return;
      if (num>0) {
        spos += num;
        stail += num;
	if (!--nfd)
	  continue;
      }
    }
    if (FD_ISSET(cfd, &rd)) {
      num=read(cfd,ctail,sizeof(cbuf)-cpos);
      if ((num==-1) && (errno != EWOULDBLOCK)) return;
	if (num==0) return;
	if (num>0) {
	  cpos += num;
	  ctail += num;
	  if (!--nfd)
	    continue;
      }
    }
    if (FD_ISSET(sfd, &wr)) {
      num=write(sfd,chead,ctail-chead);
      if ((num==-1) && (errno != EWOULDBLOCK)) return;
      if (num>0) {
        chead += num;
        if (chead == ctail) {
          chead = ctail = cbuf;
          cpos = 0;
        }
        if (!--nfd)
          continue;
      }
    }
    if (FD_ISSET(cfd, &wr)) {
      num=write(cfd,shead,stail-shead);
      if ((num==-1) && (errno != EWOULDBLOCK)) return;
      if (num>0) {
        shead += num;
        if (shead == stail) {
          shead = stail = sbuf;
          spos = 0;
        }
        if (!--nfd)
          continue;
      }
    }
  }
}




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Fri, 20 Nov 92 14:18:02 PST
To: cypherpunks@toad.com
Subject: The Cypherpunks Mail Project
Message-ID: <9211201847.AA29990@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Hey, this means you!  Have you sent me the name of the software you
use to read e-mail with yet?

Even if you've never posted to the list or replied to any of the
messages, I expect to hear from you.

I not only want to collect a list of names of software, I want to know
which ones are in most common use.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Fri, 20 Nov 92 04:11:08 PST
To: cypherpunks@toad.com
Subject: Re: How far is to far?
In-Reply-To: <199211200828.AA03551@well.sf.ca.us>
Message-ID: <1992Nov20.111126.1376@extropia.wimsey.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain


gg@well.sf.ca.us (George A. Gleason) writes:

>Re. Fen's proposal to utilise "broadcatch."  We still have the problems of
>slander/libel and breaches of legitimate secrecy.  

>At risk of sounding naive/idealistic, it would seem that since there is no
>way to block information passing through the net (aside from screening at
>source, impractical at least!), the solution rests with education of the
>net-using population.  Power carries responsibility in equal measure.  We

Nah, education is too hard. :)

There are two other options:

- Have the mix accessible to only a selected group.  Provide the group
with signed certificates.  It is possible to sign certificates such
that they are untracable to their owner, exactly like crypto money.
A security concern here is that the mix owner can tell when the
same user uses the mix more than once (but the owner can't tell
which user).

- Charge for the mix services with crypto-money.  The crypto-money
could be some networking service.  It could be even mix transmission.
For example, the basic currency could be the transmission of 10K
through a mix.  One would have to create a mix and let the bank
route some traffic through it thereby putting credits in your
account.  Once you have credits, you could spend them anywhere.
One might want to fiddle with the definition of the currency so
that it does not depreciate with time.

I prefer the second option.  I think mixes and crypto-money really
go hand in hand.
-- 
	Miron Cuperman <miron@extropia.wimsey.com>   | NeXTmail/mime ok
		       <miron@cs.sfu.ca>	     | Public key avail
	AMIX: MCuperman				     |
immortalcybercomputinglaissezfaire		     |




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 20 Nov 92 14:25:24 PST
To: hkhenson@cup.portal.com
Subject: The legality of PGP
In-Reply-To: <9211191023.1.22089@cup.portal.com>
Message-ID: <9211201648.AA19486@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: hkhenson@cup.portal.com

>Perry writes PGP is based on RSA . . . which has not granted a license
>for people to use . . . . using PGP is possibly a pattent violation . . .
>I wonder--I have RSA Mailsafe.  Do you think that would give me a license
>to use RSA if I loaded up PGP?  Keith

Doubtful -- RSA tends to be licensed on a per application per copy
basis, not on a per human basis. If it was licensed on a per-human
basis, I would have bought a personal "unlimited use" license long
ago.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Date: Fri, 20 Nov 92 14:17:44 PST
To: cypherpunks@toad.com
Subject: Re: The Dining Cryptographers Protocol
Message-ID: <9211201907.AA12713@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


Can DC-nets be used in a hierarchical or "backbone" framework to
reduce communications overhead?  

Bill Stewart (in personal mail) suggested that such a scheme could
satisfy my objections to DC-nets, namely that in order to get N-way
anonymity, you must exchange N bits of traffic per bit of anonymous
message transmitted.  But when we tried to come up with such a scheme,
it ended up being an unsatisfying hybrid of DC-nets and mixes.

If you know of a backbone arrangement for DC-nets with a local net of
size L<<N but an "anonymity parameter" of N, please tell us about it...


-- Marc Ringuette (mnr@cs.cmu.edu)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ccat@casa-next1.Stanford.EDU (Chris Beaumont)
Date: Fri, 20 Nov 92 15:04:50 PST
To: cypherpunks@toad.com
Subject: Encrypting all mail and the protection of..
Message-ID: <9211202300.AA10992@ casa-next1.Stanford.EDU >
MIME-Version: 1.0
Content-Type: text/plain



I thinat in the case of      n reading back over the debate about mail encryptionthrough the encryption debate,my main thought seems to
be,like the someone said earlier, that really the thing to push for is a
mass people's movement to encrypyt all mail as a matter of course,
with the tools to encrypt/decrypt be ing programs whose source code
is freely published and open to scrutiny.Ultimately,if ALL mail, of
any kind is routinely encrypted and decrypted using a suitable encryption
metheod,privacy will be something we will tajke for granted.This right
should be guaranteed via a Constitutional amendment.The decreasing cost of
silicon will make this increasingly practical, and the money saved through
the curtailment of credit card fraud,etc. (uncrackable digital suignatures would also have
a side-benefit in that they would eliminate most credit card fraud.)would
make this a win win situation..(except fotr the spooks and the crooks..)

-Chris.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Fri, 20 Nov 92 16:37:47 PST
To: cypherpunks@toad.com
Subject: transport
Message-ID: <9211210037.AA08344@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Is there anyone going to tommorow's meeting from bekreley that I could get a
ride from?  If so please mail me or call me at 510 559 8470.

Thanks,

Eric Hollander




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dclunie@pax.tpa.com.AU (David Clunie)
Date: Thu, 19 Nov 92 23:01:19 PST
To: cypherpunks@toad.com
Subject: Re: Some proposals, Anonymous mailers
Message-ID: <9211200659.AA00380@britt>
MIME-Version: 1.0
Content-Type: text/plain


>    I've been getting good support for my ideas on implementing machine
> independent modules or "Libraries" of PGP routines that don't include
> I/O portions,   but after looking at the code,   I see this is going to
> take a lot of work,   both in organizing the effort,   and in implementing
> the code.    Just how this is going to be done,  I'm not sure,   but this
> is what cypherpunks is all about.    To hash these things over,  flame on
> each other's ideas,  etc.
> 
>   I have been studying the PGP code,   and can see it's going to take a
> lot of work to get it into a form where true machine portability can
> be realized.   As  a Mac purist,  a abhore the idea if translating Mac
> GUI actions into ascii text and sending it to the current PGP "engine".
> 
>   Although it would take a lot of work,   I propose that we develop PGP
> to have the following form.
> 
>   a) Encryption engine library - Main set of routines currently in the
>      PGP program dealing with encryption of data.   These would be

I strongly support this concept. Having just implemented a new anonymous
mail and posting system with privacy enhancement using PGP on a Unix
machine, using the existing PGP code which is very keyboard oriented,
proved to be a real headache, trying to second guess the responses that
pgp expected. The whole deal would have been much easier calling
library routines, or even more "Unix" like tool type interfaces.

I am seriously considering rewriting some bits of PGP to do what I need
but unfortunately:

1. I don't know anything about encryption, as Phil has made obvious in
   his responses to my ideas (quite rightly so).

2. A preliminary perusal of the code makes it obvious that extracting the
   functionality from the interface is not an easy task.

However, I would be happy to volunteer my services should no one Unix
based with more PGP or encryption experience is available. I also live
outside the US at present which is a plus I guess as far as RSA is
concerned.

BTW. Re. my anonymous service - once I have Phil and Hal's suggestions
implemented feel free to use it. Send mail to "anon.info@pax.tpa.com.au".
The service is not yet really on-line, but if anyone wants to play with
it feel free (given the proviso that I might change things and take it
up and down periodically until I get it right; I will try to preserve
alias #'s and stored public keys that have already been sent along). It is
not based on the current perl scripts - I hacked it up in Bourne shell
scripts before I heard about other peoples efforts, so all bugs are mine !

Note that it is basically a typical anonymous mailing system like that
used in the various alt.personals and alt.sex groups, except that you
can encrypt your messages to it, and it will encrypt responses back to
you automatically, so dubious bounced mail and replies will not be
readable by other's at your site or on the path. At present it is set
up to allow posting to any group, but I am seriously considering blocking
out the k12 groups after the recent godiva fiasco, quite against my
philosophy, but my better judgement may yet prevail :( The same may go
for file size and even rapidly repeated messages to the same addresses
to prevent common patterns of "anonymous abuse". I hate to do this and
may not, but I get the impression that I would be foolish not to. The
immaturity of some people out there amazes me.

BTW. I have also started a new mailing list for discussion of anonymous
groups in general as well as my system. Send mail to "anon.subscribe@
pax.tpa.com.au" if you want to join. The list is strictly plaintext at
the moment though unfortunately !

david





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Brad Huntting <huntting@glarp.com>
Date: Fri, 20 Nov 92 17:10:16 PST
To: hughes@soda.berkeley.edu
Subject: Re: The Cypherpunks Mail Project
In-Reply-To: <9211201847.AA29990@soda.berkeley.edu>
Message-ID: <199211210109.AA00635@misc.glarp.com>
MIME-Version: 1.0
Content-Type: text/plain


> Hey, this means you!  Have you sent me the name of the software you
> use to read e-mail with yet?

> Even if you've never posted to the list or replied to any of the
> messages, I expect to hear from you.

> I not only want to collect a list of names of software, I want to know
> which ones are in most common use.

I use mime-mh...  A variant of mh which supports MIME.  Incorporating
pgp with MIME, and then cleaning up pgp a little so it can deal
with stdin/stdout would probably serve me just fine...


brad




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Fri, 20 Nov 92 18:47:12 PST
To: whitaker@eternity.demon.co.uk
Subject: The Cypherpunks Mail Project
In-Reply-To: <4475@eternity.demon.co.uk>
Message-ID: <9211210246.AA17433@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


    > Hey, this means you!  Have you sent me the name of the software you
    > use to read e-mail with yet?
    > 
    > Eric
    >

    PCElm 3.01.

Everyone, please send the name of your email software to Eric, so
he can do useful and wonderful things with the information.
But please *don't* clutter the rest of the list with it.  Thanks.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill O'Hanlon <wmo@rebma>
Date: Fri, 20 Nov 92 20:46:59 PST
To: hughes@soda.berkeley.edu
Subject: Re: The Cypherpunks Mail Project
In-Reply-To: <9211201847.AA29990@soda.berkeley.edu>
Message-ID: <m0mslZn-0006RkC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


I use elm and mh-6.7.  I just started using mh and am still learning my
way around it.

The platforms I use are Sun Sparcstations, at work, and 386-based PCs running
Interactive, DOS, and 386BSD at home.

Good luck with the survey,
Bill




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghoast@gnu.ai.mit.edu
Date: Fri, 20 Nov 92 19:21:02 PST
To: th@gnu.ai.mit.edu
Subject: NSA readings
Message-ID: <9211210320.AA49284@hal.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


If one is looking to find out as much as possible on the NSA (it
s past doings as well as known present doings), what should one
read, aside from the aforementioned "Puzzle Palace"?

Are there any other accurate books or articles available?





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Fri, 20 Nov 92 23:28:18 PST
To: cypherpunks@toad.com
Subject: re: The Cypherpunks Mail Project
Message-ID: <3844.2B0DE187@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: hughes@soda.berkeley.edu (Eric Hughes)

 U> Have you sent me the name of the 
 U> software you use to read e-mail with yet? 

Program: ReadMail. MSDOS, FidoNet *.MSG message base compatible.


--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Fen Labalme <fen@well.sf.ca.us>
Date: Sat, 21 Nov 92 00:35:00 PST
To: cypherpunks@toad.com
Subject: The Cypherpunks Mail Project
Message-ID: <199211210833.AA19473@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Eric Hughes writes:

>It has become clear from the discussions on the list here that the
>first step should be encrypted e-mail.  Unfortunately, mail is not
>homogeneous; there is no one place to push on the mail system to add
>encryption.

I may disagree with this (I say, "I may" as there are many sides to this
compicated issue, but the side I currently agree with I will state here)
and I hesitate to bring this up as I don't want to slow down the (imo) 
much-needed development of encrypted mailers.  But I think that an 
approach may exist that has better long-term consequences than the one
that advocates shoe-horning PGP into every mailer.

There is an attempt to to create a new mail standard on top (or next to)
the current so-called RFC-822 mail standard that will allow multi-part
typed messages.  This proposed standard, known as MIME (for Multipurpose
Internet Mail Extensions) is nearly complete and will allow rich text,
binary and other formats to be included in a single internet mail message.
There has been a disagreement between the PEM (Privacy Enhanced Mail) and
MIME communities as to which should be integrated into the other;  simply
put, the PEM folk feel that you simply encrypt an entire MIME message, and
the MIME folk think that PEM messages are just another one of the many
types of content parts that a MIME message can contain.

I tend to agree with the latter camp, as it appears to be more flexible.
For example, what happens if I wish to start communications with someone
using a different standard than PGP (gasp - they may be using RSA's
mailsafe), or even a newer, perhaps incompatible version of PGP?  Or 
maybe I want to send them a message partly encrypted and partly in the 
clear?  MIME is designed to handle these scenarios (and more).

I must admit that this thought coalesced in my head due to the confluence 
of two different streams of communications both heading towards this
solution at the same time:

1)  I asked Steve Dorner (author of the excellent Eudora Macintosh email 
    reader) if he was considering adding encryption to his mailer 
    (specifically PGP) and he replied no, but that he was integrating 
    MIME into it;
    
2)  The pem-dev email list, which has been discussing threads on PGP and 
    MIME, recently carried an interesting proposal on MIME-PEM integration
    (though I expect to see the other camp come out with their PEM-MIME 
    integration plan soon!).
    
I think this latter document is excellent reading, and I will forward it 
in a followup message to this one.  By the way, it has a short set of six
references that I consider required reading for anyone interested in doing
serious work on Internet mailers.

In case all this is new to you, I've included at the bottom a blurb from
the RFC-index explaining how to find these RFCs and more.

My $0.02.
Fen
~~~

Many RFCs are available online; if not, this is indicated by (Not online). 
Online copies are available via FTP or Kermit from NIC.DDN.MIL as 
rfc/rfc####.txt or rfc/rfc####.PS (#### is the RFC number without leading 
zeroes).

Additionally, RFCs may be requested through electronic mail from the
automated NIC mail server by sending a message to SERVICE@NIC.DDN.MIL
with a subject line of "rfc ####" for text versions or a subject line
of "rfc ####.PS" for PostScript versions.  To obtain the RFC index,
the subject line of your message should read "rfc index".




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wmo@rebma.rebma.mn.org (Bill O'Hanlon)
Date: Fri, 20 Nov 92 23:24:21 PST
To: cypherpunks@toad.com
Subject: Apology
Message-ID: <m0msoWk-0006QkC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


Oops.  Sorry about sending my response to Eric's survey to the entire
list.  Honestly, I know better, but I think that was the first time that
I've used mh's repl, and I didn't check the cc.  Oops.

Anyway, I've had a couple queries on Eric's remailer.  Hal Finney,
just so you know, I've not heard responses from you to a couple letters,
and neither has at least one other person.  We're interested in your code
for the Encrypted: part of the remailer.
-- 
Bill O'Hanlon						 wmo@rebma.mn.org




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Fen Labalme <fen@well.sf.ca.us>
Date: Sat, 21 Nov 92 00:42:36 PST
To: cypherpunks@toad.com
Subject: The Cypherpunks Mail Project
Message-ID: <199211210841.AA20896@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


To: pem-dev@TIS.COM, ietf-822@dimacs.rutgers.edu Subject: MIME-PEM Interaction
Reply-To: ietf-822@dimacs.rutgers.edu
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Mon, 16 Nov 1992 16:41:22 -0800
From: Marshall Rose <mrose@dbc.mtview.ca.us> Sender: pem-dev-relay@TIS.COM

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii" 

Friends, at the request of the participants at the SAAG meeting this afternoon, I am posting a draft regarding the interaction of MIME and PEM. I believe that this draft will be presented by Ned Freed at the PEM meeting on Wednesday (which, regrettably, I will be unable to attend due to a conflict.)

Although Steve, Ned and I think that the draft is fairly complete, there are likely some issues which remain to be resolved or at least given greater exposition. As such, your comments are most certainly welcome! 

/mtr

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii" Content-Description: mime-pem.txt





draft	MIME-PEM Interaction	Nov 92


MIME-PEM Interaction

Mon Nov 16 15:51:54 1992


Steve Crocker
Trusted Information Systems
crocker@tis.com


Ned Freed
Innosoft International, Inc.
ned@innosoft.com


Marshall T. Rose
Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us






1. Status of this Memo

This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts.

Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". 


2. Abstract

This memo defines a framework for interaction between MIME and PEM services.








Expires May 16, 1993	[Page 1]





draft	MIME-PEM Interaction	Nov 92


3. Introduction

In the Internet community, an electronic mail message has two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [1], whilst the body, if structured, is defined according to Multipurpose Internet Mail Extensions (MIME) [2]. 

Privacy Enhanced Mail (PEM) [3-6] allows encryption and authentication services to be applied to an electronic mail message.

This memo defines a framework whereby the services provided by MIME and PEM are used in a complementary fashion. 

In order to provide for MIME-PEM interaction, two content types, "multipart/pem" and "application/pem", are defined. Then, the relationship between MIME and PEM is described in terms of two functions: message composition and message delivery.






























Expires May 16, 1993	[Page 2]





draft	MIME-PEM Interaction	Nov 92


4. Definiton of new Content Types


4.1. Definition of the multipart/pem Content Type 

(1) MIME type name: multipart

(2) MIME subtype name: pem

(3) Required parameters: boundary, privacy 

(4) Optional parameters: none

(5) Encoding considerations: always 7bit 

(6) Security Considerations: see [3]


This subtype of multipart always contains two body parts: the first is an arbitrary content; and, the second is an application/pem content which describes the privacy- enhancements which resulted in the first body part. 

The value of the first body part corresponds to <pemtext> as defined in [3]. Note that if <pemtext> is represented using the base64 encoding, then a a Content-Transfer-Encoding: header is present which indicates use of the base64 content encoding. Otherwise, if a Content-Transfer-Encoding: header is present, it indicates use of the 7bit content encoding. 

The syntax and semantics of the boundary parameter is defined in [2].

The syntax of the privacy parameter, using the ABNF notation of [1], is:

privacy-value ::= "ENCRYPTED"
/ "MIC-ONLY"
/ "MIC-CLEAR"

with each value conveying the intent as specified in [3]. 









Expires May 16, 1993	[Page 3]





draft	MIME-PEM Interaction	Nov 92


4.2. Definition of the application/pem Content Type 

(1) MIME type name: application

(2) MIME subtype name: pem

(3) Required parameters: none

(4) Optional parameters: none

(5) Encoding considerations: always 7bit 

(6) Security Considerations: see [3]


The syntax of this content type corresponds to the <pemhdr> production defined in [3].

































Expires May 16, 1993	[Page 4]





draft	MIME-PEM Interaction	Nov 92


5. Message Composition

When a user composes a message, it is the responsibility of the user agent to use the Content-Type: header. This allows the receiving user agent to unambiguously interpret the body and process it accordingly.

This memo introduces a new header field, "Content-Privacy", which is used to indicate that the message should undergo privacy-enhancement prior to submission. The syntax of this header field corresponds to the <privacy-value> production defined above.


5.1. Pre-Submission Algorithm

Prior to submission, the user agent applies this algorithm: 

(1) If the content does not contain the Content-Privacy: 
header, then the user agent sees if the content is either multipart or message. If so, it then recursively applies this algorithm to the encapsulated body parts; if not, it terminates processing for this content.

(2) If the content does contain the Content-Privacy: header, 
the content is transformed from local form to its canonical form. Note that if a Content-Transfer- Encoding: header is present, then the content encoding is reversed as a part of this process.

(3) If the canonical form of the content uses octet values 
outside of the NVT ASCII repertoire, and if the value of the Content-Privacy: header is MIC-CLEAR, then this inconsistency is reported to the user and the algorithm aborts.

(4) Otherwise, the privacy-enhancement indicated by the 
Content-Privacy: header is performed, constructing a new content. The Content- headers, other than Content- Transfer-Encoding: and Content-Privacy:, are taken from the original content, if any.

(5) If the value of the Content-Privacy: header is not MIC- 
CLEAR, then the base64 content encoding is applied and a Content-Transfer-Encoding: header is added to the new 





Expires May 16, 1993	[Page 5]





draft	MIME-PEM Interaction	Nov 92


content.

(6) Finally, a multipart/pem content is constructed, whcih 
contains the new content and a corresponding application/pem content. The multipart/pem content replaces the original content.












































Expires May 16, 1993	[Page 6]





draft	MIME-PEM Interaction	Nov 92


6. Message Delivery

When a user receives a message containing an multipart/pem content, the user agent may transform the content back into its original content type. This operation, the post-delivery algorithm, is performed by reversing the steps performed during the pre-submission algorithm.

When the original content is reconstituted into canonical form, it may use octet values outside of the NVT ASCII repertoire. If the user agent replaces the multipart/pem content with the original content, then it must select an appropriate transfer encoding and include the appropriate Content-Transfer-Encoding: header.


Upon successful completion of the post-delivery algorithm for each content, the user agent adds a new header field, "Content-Annotation", which is used to indicate the privacy- enhancements that were in effect when the content was submitted. The syntax of this header field, using the ABNF notation of [1], is:

content-annotation ::= "Content-Annotation" ":" 
annotation-value

annotation-value ::= <privacy-value> ";" <date-time> 

with <privacy-value> corresponding to the privacy-enhancements that was in effect during submission, and <date-time>, defined in [1], indicates the date and time that the privacy- enhancements were verified by the receiving user agent. 

NOTE
It must be strongly emphasized that the user's level of trust in the value of the Content-Annotation: header should be no higher than the user's level of trust in the message store employed by the user agent. 












Expires May 16, 1993	[Page 7]





draft	MIME-PEM Interaction	Nov 92


7. An Example

For example, suppose the following message was being readied for submission:

Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker@tis.com
To:	ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii Content-Privacy: mic-clear

Hi Ned. See how much nicer this works!

After applying pre-submission algorithm, the message submitted for delivery would appear as:

Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker@tis.com
To:	ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/pem; boundary="next-part"; 
privacy=mic-clear

Content-Type: text/plain; charset=us-ascii 

Hi Ned. See how much nicer this works!

--next-part
Content-Type: application/pem

Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: ...
MIC-Info: RSA-MD5,RSA, ...

--next-part--











Expires May 16, 1993	[Page 8]





draft	MIME-PEM Interaction	Nov 92


After applying the post-delivery algorithm, the resulting message would appear as:

Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker@tis.com
To:	ned@innosoft.com
Subject: example #1
MIME-Version:	1.0
Content-Type:	text/plain; charset=us-ascii
Content-Annotation: mic-clear;
Thu, 12 Nov 1992 22:13:40 -0800
(integrity verified)

Hi Ned. See how much nicer this works!

Of course, as the message being submitted was only plain text, the Content-Type: header could be ommitted. In that case, after applying the pre-submission algorithm, the message submitted for delivery would appear as:

Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker@tis.com
To:	ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/pem; boundary="next-part"; 
privacy=mic-clear

Hi Ned. See how much nicer this works!

--next-part
Content-Type: application/pem

Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: ...
MIC-Info: RSA-MD5,RSA, ...

--next-part--











Expires May 16, 1993	[Page 9]





draft	MIME-PEM Interaction	Nov 92


8. Observations

The use of the pre-submission and post-delivery algorithms exhibit several properties:

(1) It allows privacy-enhancement of an arbitrary content, 
not just an RFC 822 message.

(2) For a multipart or message content, it allows the user to 
decide whether the structure of the content should receive privacy-enhancement.

(3) It allows a message to contain several privacy enhanced 
contents, thereby removing the requirement for PEM software to be able to generate or interpret a single content which intermixes both unenhanced and enhanced components.

(4) It minimizes confusion when viewing a MIC-CLEAR content 
without a PEM-capable user agent.

(5) It minimizes confusing when viewing a MIC-ONLY content 
with a MIME-capable user agent that is not PEM-capable. 


9. Acknowledgements

David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction.





















Expires May 16, 1993	[Page 10]





draft	MIME-PEM Interaction	Nov 92


10. References

[1] D.H. Crocker. Standard for the Format of ARPA Internet 
Text Messages. Request for Comments 822, (August, 1982). 

[2] N. Borenstein, N. Freed, Multipurpose Internet Mail 
Extensions. Request for Comments 1341, (June, 1992). 

[3] J. Linn, Privacy Enhancement for Internet Electronic 
Mail -- Part I: Message Encryption and Authentication Procedures. Internet-Draft, (July 23, 1992). 

[4] S. Kent, Privacy Enhancement for Internet Electronic 
Mail -- Part II: Certificate-Based Key Management. Internet-Draft, (August 6, 1992).

[5] D. Balenson, Privacy Enhancement for Internet Electronic 
Mail -- Part III: Algorithms, Modes, and Identifiers. Internet-Draft, (September 3, 1992).

[6] B. Kaliski, Privacy Enhancement for Internet Electronic 
Mail -- Part IV: Key Certification and Related Services Internet-Draft, (September 1, 1992).



























Expires May 16, 1993	[Page 11]





draft	MIME-PEM Interaction	Nov 92


Table of Contents


1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Introduction .......................................... 2 4 Definiton of new Content Types ........................ 3 4.1 Definition of the multipart/pem Content Type ........ 3 4.2 Definition of the application/pem Content Type ...... 4 5 Message Composition ................................... 5 5.1 Pre-Submission Algorithm ............................ 5 6 Message Delivery ...................................... 7 7 An Example ............................................ 8 8 Observations .......................................... 10 9 Acknowledgements ...................................... 10 10 References ........................................... 11 


































Expires May 16, 1993	[Page 12]


------- =_aaaaaaaaaa0--

[ sorry for the double spacing - my mailer's acting up and I'm too
tired to fight with it anymore.  What we need MORE than encrypted mailers
is mailers that do the standard stuff right...  The one on the WELL sux!]




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Fri, 20 Nov 92 18:17:57 PST
To: cypherpunks@toad.com
Subject: Re: The Cypherpunks Mail Project
Message-ID: <4475@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


> Hey, this means you!  Have you sent me the name of the software you
> use to read e-mail with yet?
> 
> Eric
>

PCElm 3.01.
 

Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
================ PGP 2.0 public key available =======================




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sat, 21 Nov 92 02:24:11 PST
To: miron@extropia.wimsey.com
Subject: Re: How far is to far?
Message-ID: <199211211022.AA06269@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Miron writes, 
"Charge for the mix services with crypto money.  The crypto money could be
some networking service..."

Only problem is, once we start anything like a formal barter system, it
comes under the IRS.  The way to avoid that is to keep it a volunteer
organisation with an expectation of time commitment to projects or to
payment of membership dues.  Not-for-profit organisations are of course
regulated in a minimal way (think of your local Model Railroad Club), but
the accounting isn't as strict and the membership transactions don't have to
be reported in detail.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sat, 21 Nov 92 02:40:14 PST
To: tcmay@netcom.com
Subject: Re:  "Young Men's Crypto Association," (YMCA)
Message-ID: <199211211039.AA08783@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Tim, you raise a good point about those who'll wreck for the fun of it, and
more so in reaction to any perceived ethical mainstream position.  

Re crypto-anarchy, at heart I'm in favor; in practice I'm in favor; and I
see no contradiction in promoting an internalised sense of ethics in these
areas.  The underlying deep problem is we live in a society which is
addicted to the emotions that go along with violent acts.  Ultimately that
problem needs to be addressed, and it's beyond the scope of this group to do
that, except as each of us can do things in other contexst of our civic
lives.  

The difficulty of promoting an ethic of conscience is real; but so is the
difficulty of arriving at a solution to a technical problem; and difficulty
by itself does not stop anyone.  It is erroneous to think that technical
problems are easier to solve than social ones; any of us can name ten or
more areas in which technical problems have proven incredibly complex.  In
most of these examples, the complex problems arise when dealing with
networked systems or systems involving relationships among many elements
which can vary in ways that can't be controlled.  You can see a
straightforward parallel to social problems here: the more variable
elements, the more complexity of solution.  But let's not let that stop us.

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Ittai Hershman <ittai@ans.net>
Date: Sat, 21 Nov 92 08:52:59 PST
To: cypherpunks@toad.com
Subject: Re: The Cypherpunks Mail Project
In-Reply-To: <199211210833.AA19473@well.sf.ca.us.ans-relay>
Message-ID: <199211211650.AA02274@shemesh.ans.net>
MIME-Version: 1.0
Content-Type: text/plain


I am in full agreement with Fen's comments regarding MIME.  Let me add
a short bit of history here.  MIME came about because of an effort
within the IETF (Internet Engineering Task Force) to extend Internet
mail standards to support 8-bit extended character sets and (gasp) to
potentially even support the sending of arbitrary binary data.  A
working group was formed and it took several months and literally
thousands of messages before some form of consensus was reached on the
technical issues (note -- not the solution, just the issues!).

To make a long story short, it quickly became obvious that there was
no agreed upon solution which would both provide the functionality the
various camps wanted, and backwards compatability for the million or
so hosts currently on the Internet.  The MIME effort was a creative
stroke of genius which allowed us to get out of this fix.  Simply put,
it allows for a) arbitrary data types to be encoded into 7-bit ASCII
and transported using standard RFC-821 SMTP, and b) the structuring of
chunks of different data type "parts" into a single e-mail message
such that MIME-aware mail-agents/readers can intelligently display
multi-media mail intelligently.  In other words, the problem was moved
from the protocol space to the applications space.

Why is this relevant?  Well, in order for MIME to be useful, the mail
readers that people use have to be modified to support MIME.
Fortunately, Nathaniel Borenstein of Bellcore has assembled a kit to
make this much easier, and in fact provides patches for many mailers.
Now, the authors of all the freebie mail readers we use are being
asked to incorporate these changes into their mailers.  Do we really
want to give them an additional burden -- or do we want to leverage
off work that is already being done?

-Ittai

PS:  For those who are interested, these are the relevant RFC's:

1344  Implications of MIME for Internet mail gateways.  Borenstein, N.  1992 
      June; 8 p. (Format: TXT=25872, PS=51812 bytes)

1343  User agent configuration mechanism for multimedia mail format 
      information.  Borenstein, N.  1992 June; 10 p. (Format: TXT=29295, 
      PS=59978 bytes)

1342  Representation of non-ASCII text in Internet message headers.  Moore, K.
      1992 June; 7 p. (Format: TXT=15845 bytes)

1341  MIME (Multipurpose Internet Mail Extensions): Mechanisms for specifying 
      and describing the format of Internet message bodies.  Borenstein, N.; 
      Freed, N.  1992 June; 69 p. (Format: TXT=211117, PS=347082 bytes)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: donb@netcom.com (Don Bellenger)
Date: Sat, 21 Nov 92 21:16:52 PST
To: cypherpunks@toad.com
Subject: SUBSCRIBE
Message-ID: <9211220512.AA07634@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


SUBSCRIBE
Please add me to your mailing list at this address.
Thanks,
Don Bellenger
donb@netcom.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Sun, 22 Nov 92 05:02:03 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Problems with remailer
Message-ID: <XZ2muB4w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


Distribution:
    Hal           <74076.1041@compuserve.com>
    Cypherpunks   <cypherpunks@toad.com>
 
Hal:
 
I tried to test your remailer, but didn't have any luck. I can see
that other people (Cassandra & Pollyanna among others) are using it.
 
This small (and free) system does not allow me to specify network
headers (except Subject), so I used the "::"  convention.  I tried
three configurations of sending something to myself on Nov 17, 1:08am.
As of my last session, Nov 19, 4:45pm, I had not received an echo from
any of the three.  Here is the record of the mailings.  Note the
sequence numbers are not part of the message.
----------------------------------------------------------------
To: Remailing Service <hal@alumni.caltech.edu>
Subject:  Remail Unincrypted
 
  1> ::
  2> Request-Remailing-To: edgar@spectrx.saigon.com (Edgar W. Swank)
  3>
  4> This is an unencrypted test message.
  5> /s
        (Queued for Internet delivery)
 
To: Remailing Service <hal@alumni.caltech.edu>
Subject: Remail Encrypted
c:\tlxd\spies7.msg  <Input to PGP>
::
Request-Remailing-To: edgar@spectrx.saigon.com (Edgar W. Swank)
 
This is an encrypted test message.
c:\tlxd\spies7.asc  <Output of PGP>
 
  1> ::
  2> Encrypted: PGP
  3>
  4> -----BEGIN PGP MESSAGE-----
  5> Version: 2.0
  6>
  7> hEwCG6rHcT8LtDcBAf4ime6fkvJE3hKvET5lNeG7U51cFM5B9bCRuYdgDN8gXGef
  8> tXpamyWSXHDRvpb/PeebBdG/Gqxb571l54vqAO5opgAAAIepaWGSNzSfnMSOWV+a
  9> VFETSI7H7i2m3ZagT/XbgVqzfVUXkkqBYXKESlcsAiUWnF8tXGwYJ/KYUvHWW/ve
 10> qPvlbdYAoe+iMtR7asvPCEz+WxEmdIQqTxUPCT1tiIaaplsk5l7p80dW8NkArCH6
 11> BTowA85FQrI7gBUBevSs8hq62JUAs6GH5T8=
 12> =XUQk
 13> -----END PGP MESSAGE-----
 14>
 15> /s
        (Queued for Internet delivery)
 
To: Remailing Service <hal@alumni.caltech.edu>
Subject: Remail With Anon Return
 
  1> ::
  2> Encrypted: PGP
  3>
  4> -----BEGIN PGP MESSAGE-----
  5> Version: 2.0
  6>
  7> hEwCG6rHcT8LtDcBAf0SgMh0C4raXWqjXytzsmpt2b8veBXZhUvez+ZI309w1Y8w
  8> oiYcPjGHhL6l7ad0IXuXFUgBwxAmHbzexSLVeKvgpgAAAGuiL3psLLLJfKeDGXjD
  9> hDK3KWoFGlzyzssiudBe+f5kv/1j4EnzkviyQgxCxFTYUd04Z6az1HWRWU7Fvanq
 10> KZarLLBgfe8eqzIa82FyOh6CMFqg2Ou4VkaTbQma8LQk4u+7JRNxKBMmy7TrTQ==
 11> =0mFO
 12> -----END PGP MESSAGE-----
 13>
 14> This is a message using anonymous return address.
 15> /s
        (Queued for Internet delivery)
----------------------------------------------------------------
Hope you can tell me where I went wrong, especially since you
have the convenience of the remailer secret key.
 
In one post, you said:
 
    You could post anonymously, using our current remailers, to this
    list or another list.
 
This implies you now have more than one remailer.  Where is (are) the
other one(s)?
 
I've since lost track of the details, but I recall reading about
a gateway from E-Mail to any Usenet newsgroup. Of course, with your
remailer, it's now possible to use that to anonymously post to any
usenet newsgroup.
 
Since I'm writing to you anyway, I'd be interested in knowing what
(if any) records are kept by the remailer, and for how long are they
retained. Where the forwarding address is encrypted, is the decryption
of same erased both in memory & on disk (overlay erased on disk) as
soon as the message is sent? Memory buffers of incoming net headers
(which aren't encrypted) and messages (which may not be encrypted)
also need to be erased promptly & not left lying around until reused.
 
Is it possible the remailer held up forwarding my messages waiting
for other messages to arrive with different destinations (to confuse
traffic analysis)?  To avoid long waits, you might want to send
out dummy messages to a variety of addresses when traffic is low.
I hereby volunteer my address to receive up to ten such messages
per day. Once there are enough remailers so that most messages are
being forwarded to another remailer, then all the dummy messages
can be sent to the other remailers.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sun, 22 Nov 92 11:54:53 PST
To: cypherpunks@toad.com
Subject: Crypto Glossary
Message-ID: <9211221950.AA28744@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Here's the glossary of crypto terms we passed out in printed form at
the first Cypherpunks meeting in September 1992. Some compromises had
to be made in going from the printed form to the ASCII of this
transmission, so I hope you'll bear with me.

I'm sending it to the entire list because nearly everyone who hears
about it says "Is it online?" and wants a copy. If you don't want it,
discard it.

I'm not going to be maintaining the "Cypherpunks FAQ," so don't send
me corrections or additions.

Enjoy!

--Tim May


CRYPTO GLOSSARY

Compiled by Tim May (tcmay@netcom.com) and Eric Hughes
(hughes@soda.berkeley.edu), circa September 1992.

Major Branches of Cryptology (as we see it)

-	(these sections will introduce the terms in context, 
though complete definitions will not be given)

*** Encryption
-	privacy of messages
-	using ciphers and codes to protect the secrecy of 
messages
-	DES is the most common symmetric cipher (same key for 
encryption and decryption)
-	RSA is the most common asymmetric cipher (different 
keys for encryption and decryption)

*** Signatures and Authentication
-	proving who you are
-	proving you signed a document (and not someone else)

*** Untraceable Mail
-	untraceable sending and receiving of mail and messages
-	focus: defeating eavesdroppers and traffic analysis
-	DC protocol (dining cryptographers)

*** Cryptographic Voting
-	focus: ballot box anonymity
-	credentials for voting
-	issues of double voting, security, robustness, efficiency

*** Digital Cash
-	focus: privacy in transactions, purchases
-	unlinkable credentials
-	blinded notes
-	"digital coins" may not be possible

*** Crypto Anarchy
-	using the above to evade government, to bypass tax collection, 
etc.
-	a technological solution to the problem of too much 
government



***	G L O S S A R Y    ***


***	agoric systems -- open, free market systems in which 
voluntary transactions are central. 

***	Alice and Bob -- cryptographic protocols are often made 
clearer by considering parties A and B, or Alice and Bob, 
performing some protocol. Eve the eavesdropper, Paul the 
prover, and Vic the verifier are other common stand-in names.

***	ANDOS -- all or nothing disclosure of secrets.

***	anonymous credential -- a credential which asserts 
some right or privilege or fact without revealing the identity 
of the holder.  This is unlike CA driver's licenses.

***	asymmetric cipher -- same as public key 
cryptosystem.

***	authentication -- the process of verifying an identity 
or credential, to ensure you are who you said you were.

***	biometric security -- a type of authentication using 
fingerprints, retinal scans, palm prints, or other 
physical/biological signatures of an individual.

***	bit commitment -- e.g., tossing a coin and then 
committing to the value without being able to change the 
outcome. The blob is a cryptographic primitive for this.

***	blinding, blinded signatures -- A signature that the 
signer does not remember having made.  A blind signature is 
always a cooperative protocol and the receiver of the 
signature provides the signer with the blinding information. 

***	blob -- the crypto equivalent of a locked box. A 
cryptographic primitive for bit commitment, with the 
properties that a blobs can represent a 0 or a 1, that others 
cannot tell be looking whether itUs a 0 or a 1, that the creator 
of the blob can "open" the blob to reveal the contents, and that 
no blob can be both a 1 and a 0. An example of this is a flipped 
coin covered by a hand.

***	channel -- the path over which messages are 
transmitted. Channels may be secure or insecure, and may 
have eavesdroppers (or enemies, or disrupters, etc.) who alter 
messages, insert and delete messages, etc. Cryptography is 
the means by which communications over insecure channels 
are protected.

***	chosen plaintext attack -- an attack where the 
cryptanalyst gets to choose the plaintext to be enciphered, 
e.g., when possession of an enciphering machine or algorithm 
is in the possession of the cryptanalyst.

***	cipher -- a secret form of writing, using substitution or 
transposition of characters or symbols.

***	ciphertext -- the plaintext after it has been encrypted.

***	code -- a restricted cryptosystem where words or 
letters of a message are replaced by other words chosen from 
a codebook. Not part of modern cryptology, but still useful.

***	coin flipping -- an important crypto primitive, or 
protocol, in which the equivalent of flipping a fair coin is 
possible. Implemented with blobs.

***	collusion -- wherein several participants cooperate to 
deduce the identity of a sender or receiver, or to break a 
cipher. Most cryptosystems are sensitive to some forms of 
collusion. Much of the work on implementing DC Nets, for 
example, involves ensuring that colluders cannot isolate 
message senders and thereby trace origins and destinations 
of mail.

***	computationally secure -- where a cipher cannot be 
broken with available computer resources, but in theory can 
be broken with enough computer resources. Contrast with 
unconditionally  secure.

***	countermeasure -- something you do to thwart an 
attacker.

***	credential -- facts or assertions about some entity. For 
example, credit ratings, passports, reputations, tax status, 
insurance records, etc.  Under the current system, these 
credentials are increasingly being cross-linked. Blind 
signatures may be used to create anonymous credentials.

***	credential clearinghouse  -- banks, credit agencies, 
insurance companies, police departments, etc., that correlate 
records and decide the status of records. 

***	cryptanalysis -- methods for attacking and breaking 
ciphers and related cryptographic systems. Ciphers may be 
broken, traffic may be analyzed, and passwords may be 
cracked. Computers are of course essential.

***	crypto anarchy -- the economic and political system 
after the deployment of encryption, untraceable e-mail, 
digital pseudonyms, cryptographic voting, and digital cash. A 
pun on "crypto," meaning "hidden," and as when Gore Vidal 
called William F. Buckley a "crypto fascist."

***	cryptography -- another name for cryptology.

***	cryptology -- the science and study of writing, sending, 
receiving, and deciphering secret messages. Includes 
authentication, digital signatures, the hiding of messages 
(steganography), cryptanalysis, and several other fields.

***	cyberspace  -- the electronic domain, the Nets, and 
computer-generated spaces. Some say it is the "consensual 
reality" described in "Neuromancer." Others say it is the phone 
system. Others have work to do.

***	DC protocol, or DC-Net -- the dining cryptographers 
protocol. DC-Nets use multiple participants communicating 
with the DC protocol.

***	DES -- the Data Encryption Standard, proposed in 
1977 by the National Bureau of Standards (now NIST), with 
assistance from the National Security Agency. Based on the 
"Lucifer" cipher developed by Horst Feistel at IBM, DES is a 
secret key cryptosystem that cycles 64-bit blocks of data 
through multiple permutations with a 56-bit key controlling 
the routing. "Diffusion" and "confusion" are combined to form 
a cipher that has not yet been cryptanalyzed (see "DES, 
Security of"). DES is in use for interbank transfers, as a 
cipher inside of several RSA-based systems, and is available 
for PCs.

***	DES, Security of  -- many have speculated that the NSA 
placed a trapdoor (or back door) in DES to allow it to read 
DES-encrypted messages. This has not been proved. It is 
known that the original Lucifer algorithm used a 128-bit key 
and that this key length was shortened to 64 bits (56 bits 
plus 8 parity bits), thus making exhaustive search much 
easier (so far as is known, brute-force search has not been 
done, though it should be feasible today). Shamir and Bihan 
have used a technique called "differential cryptanalysis" to 
reduce the exhaustive search needed for chosen plaintext 
attacks (but with no import for ordinary DES).

***	differential cryptanalysis -- the Shamir-Biham 
technique for cryptanalyzing DES. With a chosen plaintext 
attack, they've reduced the number of DES keys that must be 
tried from about 2^56 to about 2^47 or less. Note, however, 
that rarely can an attacker mount a chosen plaintext attack 
on DES systems.

***	digital cash, digital money -- Protocols for 
transferring value, monetary or otherwise, electronically.  
Digital cash usually refers to systems that are anonymous. 
Digital money systems can be used to implement any quantity 
that is conserved, such as points, mass, dollars, etc.  There 
are many variations of  digital money systems, ranging from 
VISA numbers to blinded signed digital coins.  A topic too 
large for a single glossary entry.

***	digital pseudonym -- basically, a "crypto identity." A 
way for individuals to set up accounts with various 
organizations without revealing more information than they 
wish. Users may have several digital pseudonyms, some used 
only once, some used over the course of many years. Ideally, 
the pseudonyms can be linked only at the will of the holder. In 
the simplest form, a public key can serve as a digital 
pseudonym and need not be linked to a physical identity.

***	digital signature --  Analogous to a written signature 
on a document. A modification to a message that only the 
signer can make but that everyone can recognize.  Can  be used 
legally to contract at a distance.

***	digital timestamping -- one function of a digital 
notary public, in which some message (a song, screenplay, lab 
notebook, contract, etc.) is stamped with a time that cannot 
(easily) be forged. 

***	dining cryptographers protocol (aka DC protocol, 
DC nets) -- the untraceable message sending system 
invented by David Chaum. Named after the "dining 
philosophers" problem in computer science, participants form 
circuits and pass messages in such a way that the origin 
cannot be deduced, barring collusion. At the simplest level, 
two participants share a key between them. One of them 
sends some actual message by bitwise exclusive-ORing the 
message with the key, while the other one just sends the key 
itself. The actual message from this pair of participants is 
obtained by XORing the two outputs. However, since nobody 
but the pair knows the original key, the actual message 
cannot be traced to either one of the participants.

***	discrete logarithm problem -- given integers a, n, 
and x, find some integer m such that a^m mod n = x, if m 
exists. Modular exponentiation, the a^m mod n part, is 
straightforward (and special purpose chips are available), but 
the inverse problem is believed to be very hard, in general.  
Thus it is conjectured that modular exponentiation is a one-
way function.

***	DSS, Digital Signature Standard -- the latest NIST 
(National Institute of Standards and Technology, successor to 
NBS) standard for digital signatures. Based on the El Gamal 
cipher, some consider it weak and poor substitute for RSA-
based signature schemes.

***	eavesdropping, or passive wiretapping -- 
intercepting messages without detection. Radio waves may be 
intercepted, phone lines may be tapped, and computers may 
have RF emissions detected. Even fiber optic lines can be 
tapped.

***	factoring -- Some large numbers are difficult to factor. 
It is conjectured that there are no feasible--i.e."easy," less 
than exponential in size of number-- factoring methods. It is 
also an open problem whether RSA may be broken more easily 
than by factoring the modulus (e.g., the public key might 
reveal information which simplifies the problem). 
Interestingly, though factoring is believed to be "hard", it is 
not known to be in the class of NP-hard problems. Professor 
Janek invented a factoring device, but he is believed to be 
fictional.

***	information-theoretic security -- "unbreakable" 
security, in which no amount of cryptanalysis can break a 
cipher or system. One time pads are an example (providing the 
pads are not lost nor stolen nor used more than once, of 
course). Same as unconditionally secure.

***	key -- a piece of information needed to encipher or 
decipher a message. Keys may be stolen, bought, lost, etc., 
just as with physical keys.

***	key exchange, or key distribution -- the process of 
sharing a key with some other party, in the case of symmetric 
ciphers, or of distributing a  public key in an asymmetric 
cipher. A major issue is that the keys be exchanged reliably 
and without compromise. Diffie and Hellman devised one such 
scheme, based on the discrete logarithm problem. 

***	known-plaintext attack -- a cryptanalysis of a cipher 
where plaintext-ciphertext pairs are known. This attack 
searches for an unknown key. Contrast with the chosen 
plaintext attack, where the cryptanalyst can also choose the 
plaintext to be enciphered.

***	mail, untraceable  -- a system for sending and 
receiving mail without traceability or observability. 
Receiving mail anonymously can be done with broadcast of the 
mail in encrypted form.  Only the intended recipient (whose 
identity, or true name, may be unknown to the sender) may 
able to decipher the message. Sending mail anonymously 
apparently requires mixes or use of the dining cryptographers 
(DC) protocol.

***	minimum disclosure proofs  -- another name for zero 
knowledge proofs, favored by Chaum.

***	mixes -- David Chaum's term for a box which performs 
the function of mixing, or decorrelating, incoming and 
outgoing electronic mail messages. The box also strips off 
the outer envelope (i.e., decrypts with its private key) and 
remails the message to the address on the inner envelope. 
Tamper-resistant modules may be used to prevent cheating 
and forced disclosure of the mapping between incoming and 
outgoing mail. A sequence of many remailings effectively 
makes tracing sending and receiving impossible. Contrast this 
with the software version, the DC protocol.

***	modular exponentiation  -- raising an integer to the 
power of another integer, modulo some integer. For integers 
a, n, and m, a^m mod n. For example, 5^3 mod 100 = 25. Modular 
exponentiation can be done fairly quickly with a sequence of 
bit shifts and adds, and special purpose chips have been 
designed. See also discrete logarithm.

***	National Security Agency (NSA)  -- the largest 
intelligence agency, responsible for making and breaking 
ciphers, for intercepting communications, and for ensuring 
the security of U.S. computers. Headquartered in Fort Meade, 
Maryland, with many listening posts around the world.  The 
NSA funds cryptographic research and advises other agencies 
about cryptographic matters. The NSA once obviously had the 
world's leading cryptologists, but this may no longer be the 
case.

***	negative credential -- a credential that you possess 
that you don't want any one else to know, for example, a 
bankruptcy filing.  A formal version of a negative reputation.

***	NP-complete -- a large class of difficult problems.  
"NP" stands for nondeterministic polynomial time, a class of 
problems thought in general not to have feasible algorithms 
for their solution.  A problem is "complete"  if  any other NP 
problem may be reduced to that problem.   Many important 
combinatorial and algebraic problems are NP-complete: the 
traveling salesman problem, the Hamiltonian cycle problem, 
the word problem, and on and on.

***	oblivious transfer -- a cryptographic primitive that 
involves the probabilistic transmission of bits. The sender 
does not know if the bits were received.

***	one-time pad -- a string of randomly-selected bits or 
symbols which is combined with a plaintext message to 
produce the ciphertext. This combination may be shifting 
letters some amount, bitwise exclusive-ORed, etc.). The 
recipient, who also has a copy of the one time pad, can easily 
recover the plaintext. Provided the pad is only used once and 
then destroyed, and is not available to an eavesdropper, the 
system is perfectly secure, i.e., it is information-
theoretically secure. Key distribution (the pad)  is obviously a 
practical concern, but consider CD-ROM's.

***	one-way function -- a function which is easy to 
compute in one direction but hard to find any inverse for, e.g. 
modular exponentiation, where the inverse problem is known 
as the discrete logarithm problem. Compare the special case 
of trap door one-way functions.  An example of  a one-way 
operation is multiplication: it is  easy to multiply two 
prime numbers of 100 digits to produce a 200-digit number, 
but  hard to factor that 200-digit number. 

***	P ?=? NP  -- Certainly the most  important unsolved 
problem in complexity theory. If P = NP, then cryptography as 
we know it today does not exist.  If P = NP,  all NP problems 
are "easy." 

***	padding -- sending extra messages to confuse 
eavesdroppers and to defeat traffic analysis.   Also adding 
random bits to a message to be enciphered.

***	plaintext -- also called cleartext, the text that is to be 
enciphered.

***	Pretty Good Privacy (PGP)  -- Phillip ZimmermanUs 
implementation of RSA, recently upgraded to version 2.0, 
with more robust components and several new features. RSA 
Data Security has threatened PZ so he no longer works on it.  
Version 2.0 was written by a consortium of non-U.S. hackers.

***	prime numbers -- integers with no factors other than 
themselves and 1. The number of primes is unbounded.  About 
1% of the 100 decimal digit numbers are prime.  Since there 
are about 10^70 particles in the universe, there are about 
10^23  100 digit primes for each and every particle in the 
universe!

***	probabilistic encryption  -- a scheme by Goldwasser, 
Micali, and Blum that allows multiple ciphertexts for the 
same plaintext, i.e., any given plaintext may have many 
ciphertexts if the ciphering is repeated. This protects against 
certain types of known ciphertext attacks on RSA.

***	proofs of identity -- proving who you are, either your 
true name, or your digital identity. Generally, possession of 
the right key is sufficient proof (guard your key!). Some work 
has been done on "is-a-person" credentialling agencies, using 
the so-called Fiat-Shamir protocol...think of this as a way to 
issue unforgeable digital passports. Physical proof of identity 
may be done with biometric security methods. Zero knowledge 
proofs of identity reveal nothing beyond the fact that the 
identity is as claimed. This has obvious uses for computer 
access, passwords, etc.

***	protocol -- a formal procedure for solving some 
problem. Modern cryptology is mostly about the study of 
protocols for many problems, such as coin-flipping, bit 
commitment (blobs), zero knowledge proofs, dining 
cryptographers, and so on.

***	public key -- the key distributed publicly to potential 
message-senders. It may be published in a phonebook-like 
directory or otherwise sent. A major concern is the validity 
of this public key to guard against spoofing or impersonation.

***	public key cryptosystem -- the modern breakthrough 
in cryptology, designed by Diffie and Hellman, with 
contributions from several others. Uses trap door one-way 
functions so that encryption may be done by anyone with 
access to the "public key" but decryption may be done only by 
the holder of the "private key." Encompasses public key 
encryption, digital signatures, digital cash, and many other 
protocols and applications.

***	public key encryption -- the use of modern 
cryptologic methods to provided message security and 
authentication. The RSA algorithm is the most widely used 
form of public key encryption, although other systems exist. 
A public key may be freely published, e.g., in phonebook-like 
directories, while the corresponding private key is closely 
guarded.

***	public key patents  -- M.I.T. and Stanford, due to the 
work of Rivest, Shamir, Adleman, Diffie, Hellman, and Merkle, 
formed Public Key Partners to license the various public key, 
digital signature, and RSA patents. These patents, granted in 
the early 1980s, expire in the between 1998 and 2002. PKP 
has licensed RSA Data Security Inc., of Redwood City, CA, 
which handles the sales, etc.

***	quantum cryptography -- a system based on quantum-
mechanical principles. Eavesdroppers alter the quantum state 
of the system and so are detected. Developed by Brassard and 
Bennett, only small laboratory demonstrations have been 
made.

***	reputations -- the trail of positive and negative 
associations and judgments that some entity accrues. Credit 
ratings, academic credentials, and trustworthiness are all 
examples. A digital pseudonym will accrue these reputation 
credentials based on actions, opinions of others, etc. In 
crypto anarchy, reputations and agoric systems will be of 
paramount importance. There are many fascinating issues of 
how reputation-based systems work, how credentials can be 
bought and sold, and so forth.

***	RSA -- the main public key encryption algorithm, 
developed by Ron Rivest, Adi Shamir, and Kenneth Adleman. It 
exploits the difficulty of factoring large numbers to create a 
private key and public key. First invented in 1978, it remains 
the core of modern public key systems. It is usually much 
slower than DES, but special-purpose modular exponentiation 
chips will likely speed it up. A popular scheme for speed is to 
use RSA to transmit session keys and then a high-speed 
cipher like DES for the actual message text.
***	Description -- Let p and q be large primes, typically with more than 
100 digits. Let n = pq and find some e such that e is relatively prime to (p 
- 1)(q - 1). The set of numbers p, q, and e is the private key for RSA. The 
set of numbers n and e forms the public key (recall that knowing n is not 
sufficient to easily find p and q...the factoring problem).  A message M is 
encrypted by computing M^e mod n. The owner of the private key can 
decrypt the encrypted message by exploiting number theory results, as 
follows. An integer d is computed such that ed =1 (mod (p - 1)(q - 1)). 
Euler proved a theorem that M^(ed) = M mod n and so M^(ed) mod n = M. 
This means that in some sense the integers e and d are "inverses" of each 
other. [If this is unclear, please see one of the many texts and articles on 
public key encryption.]

***	secret key cryptosystem -- A system which uses the 
same key to encrypt and decrypt traffic at each end of a 
communication link.  Also called a symmetric or one-key 
system.  Contrast with public key cryptosystem.

***	smart cards -- a computer chip embedded in credit 
card.  They can hold cash, credentials, cryptographic keys, 
etc. Usually these are built with some degree of tamper-
resistance. Smart cards may perform part of a crypto 
transaction, or all of it. Performing part of it may mean 
checking the computations of a more powerful computer, e.g., 
one in an ATM.

***	spoofing, or masquerading -- posing as another user. 
Used for stealing passwords, modifying files, and  stealing 
cash. Digital signatures and other authentication methods are 
useful to prevent this. Public keys must be validated and 
protected to ensure that others don't substitute their own 
public keys which users may then unwittingly use.

***	steganography -- a part of cryptology dealing with 
hiding messages and obscuring who is sending and receiving 
messages. Message traffic is often padded to reduce the 
signals that would otherwise come from a sudden beginning 
of messages.

***	symmetric cipher -- same as private key 
cryptosystem.
 
***	tamper-responding modules, tamper-resistant 
modules (TRMs) -- sealed boxes or modules which are hard 
to open, requiring extensive probing and usually leaving ample 
evidence that the tampering has occurred. Various protective 
techniques are used, such as special metal or oxide layers on 
chips, armored coatings, embedded optical fibers, and other 
measures to thwart analysis. Popularly called "tamper-proof 
boxes." Uses include: smart cards, nuclear weapon initiators, 
cryptographic key holders, ATMs, etc.

***	tampering, or active wiretapping -- interfering with 
messages and possibly modifying them. This may compromise 
data security, help to break ciphers, etc.  See also spoofing.

***	token -- some representation, such as ID cards, subway 
tokens, money, etc., that indicates possession of some 
property or value. 

***	traffic analysis -- determining who is sending or 
receiving messages by analyzing packets, frequency of 
packets, etc. A part of steganography. Usually handled with 
traffic padding.

***	transmission rules -- the protocols for determining 
who can send messages in a DC protocol, and when. These 
rules are needed to prevent collision and deliberate jamming 
of the channels.

***	trap messages -- dummy messages in DC Nets which 
are used to catch jammers and disrupters. The messages 
contain no private information and are published in a blob 
beforehand so that the trap message can later be opened to 
reveal the disrupter. (There are many strategies to explore 
here.)

***	trap-door -- In cryptography, a piece of secret 
information that allows the holder of a private key to invert a 
normally hard to invert function.

***	trap-door one way functions -- functions which are 
easy to compute in both the forward and reverse direction but 
for which the disclosure of an algorithm to compute the 
function in the forward direction does not provide 
information on how to compute the function in the reverse 
direction. More simply put, trap-door one way functions are 
one way for all but the holder of the secret information. The 
RSA algorithm is the best-known example of such a function.

***	unconditional security -- same as information-
theoretic security, that is, unbreakable except by loss or 
theft of the key.

***	unconditionally  secure -- where no amount of 
intercepted ciphertext is enough to allow the cipher to be 
broken, as with the use of a one-time pad cipher. Contrast 
with computationally secure.

***	voting, cryptographic -- Various schemes have been 
devised for anonymous, untraceable voting. Voting schemes 
should have several properties: privacy of the vote, security 
of the vote (no multiple votes), robustness against disruption 
by jammers or disrupters, verifiability (voter has confidence 
in the results), and efficiency.

***	zero knowledge proofs -- proofs in which no 
knowledge of the actual proof is conveyed. Peggy the Prover 
demonstrates to Sid the Skeptic that she is indeed in 
possession of some piece of knowledge without actually 
revealing any of that knowledge. This is useful for access to 
computers, because eavesdroppers or dishonest sysops cannot 
steal the knowledge given. Also called minimum disclosure 
proofs. Useful for proving possession of some property, or 
credential, such as age or voting status, without revealing 
personal information.





-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sun, 22 Nov 92 12:15:22 PST
To: cypherpunks@toad.com
Subject: The Crypto Anarchist Manifesto
Message-ID: <9211222011.AA29961@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks of the World,

Several of you at the "physical Cypherpunks" gathering yesterday in
Silicon Valley requested that more of the material passed out in
meetings be available electronically to the entire readership of the
Cypherpunks list, spooks, eavesdroppers, and all. <Gulp>

Here's the "Crypto Anarchist Manifesto" I read at the September 1992
founding meeting. It dates back to mid-1988 and was distributed to
some like-minded techno-anarchists at the "Crypto '88" conference and
then again at the "Hackers Conference" that year. I later gave talks
at Hackers on this in 1989 and 1990.

There are a few things I'd change, but for historical reasons I'll
just leave it as is. Some of the terms may be unfamiliar to you...I
hope the Crypto Glossary I just distributed will help.

(This should explain all those cryptic terms in my .signature!)

--Tim May

...................................................

The Crypto Anarchist Manifesto

Timothy  C.  May
tcmay@netcom.com


A specter is haunting the modern world, the specter of crypto 
anarchy. 

Computer technology is on the verge of providing the ability for 
individuals and groups to communicate and interact with each other 
in a totally anonymous manner. Two persons may exchange 
messages, conduct business, and negotiate electronic contracts 
without ever knowing the True Name, or legal identity, of the other. 
Interactions over networks will be untraceable, via extensive re-
routing of encrypted packets and tamper-proof boxes which 
implement cryptographic protocols with nearly perfect assurance 
against any tampering. Reputations will be of central importance, far 
more important in dealings than even the credit ratings of today. 
These developments will alter completely the nature of government 
regulation, the ability to tax and control economic interactions, the 
ability to keep information secret, and will even alter the nature of 
trust and reputation.

The technology for this revolution--and it surely will be both a social 
and economic revolution--has existed in theory for the past decade. 
The methods are based upon public-key encryption, zero-knowledge 
interactive proof systems, and various software protocols for 
interaction, authentication, and verification. The focus has until now 
been on academic conferences in Europe and the U.S., conferences 
monitored closely by the National Security Agency. But only recently 
have computer networks and  personal computers attained sufficient 
speed to make the ideas practically realizable. And the next ten 
years will bring enough additional speed to make the ideas 
economically feasible and essentially unstoppable. High-speed 
networks, ISDN, tamper-proof boxes, smart cards, satellites,  Ku-band 
transmitters, multi-MIPS personal computers, and encryption chips 
now under development will be some of the enabling technologies. 

The State will of course try to slow or halt the spread of this 
technology, citing national security concerns, use of the technology 
by drug dealers and tax evaders, and fears of societal disintegration. 
Many of these concerns will be valid; crypto anarchy will allow 
national secrets to be trade freely and will allow illicit and stolen 
materials to be traded. An anonymous computerized market will 
even make possible abhorrent markets for assassinations and 
extortion. Various criminal and foreign elements will be active users 
of CryptoNet. But this will not halt the spread of crypto anarchy.

Just as the technology of printing altered and reduced the power of 
medieval guilds and the social power structure, so too will 
cryptologic methods fundamentally alter the nature of corporations 
and of government interference in economic transactions. Combined 
with emerging information markets, crypto anarchy will create a 
liquid market for any and all material which can be put into words 
and pictures. And just as a seemingly minor invention like barbed 
wire made possible the fencing-off of vast ranches and farms, thus 
altering forever the concepts of land and property rights in the 
frontier West, so too will the seemingly minor discovery out of an 
arcane branch of mathematics come to be the wire clippers which 
dismantle the barbed wire around intellectual property.

Arise, you have nothing to lose but your barbed wire fences!


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.









From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Mon, 23 Nov 92 02:17:59 PST
To: cypherpunks@toad.com
Subject: Status on Mac PGP
Message-ID: <9211231013.AA10065@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Greetings cypherpunks:

   Talked to Phiil Zimmerman on phone this evening,  and he recommends
that the current Mac team be devided up into teo parts.   One a
short term team which no doubt will be what exists already,  and
a long term team to do a more Mac'ish GUI.  I agreed to do that,
and Phil is planning to set up a phone conference call with the
entire Mac PGP team to introduce the new proposals to everyone
at once.  this meeting will happen sometime early this week,  and
I'll be giving reports on what has transpired.

   I also sent to each of the Mac PGP members the details of the
cypherspace meeting,  but have not yet mentioned my proposal to 
help manage the team,   as I want to meet everyone first.

   I also agreed to make up a function list of the C functions in the
PGP program (Which I usually do when I study new code),   and will send 
it to anyone who wants it.   

   Oh!! By the way,  If I start up the existing Mac PGP,  running
Microphone II at the same time.    Then,  when I encrypt a file,
it hangs up the system.    This only hangs up when I decrypt a file
first,  then I go into editor to edit a file,  and save it.   After
saving the plaintext file,  then I encrypt it,   it will hang up the Mac
and needs resetting.   It requires a COLD boot,  and not a simple
reset.   Has anyone else experienced this problem?  I suspect that
a new version of Mac PGP might soon become available.   Hmmm  I must
start thinking of what the ICON should look like!!

More later....

John D.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: andrew m. boardman <amb@cs.columbia.edu>
Date: Mon, 23 Nov 92 02:02:28 PST
To: pmetzger@shearson.com
Subject: The legality of PGP
In-Reply-To: <9211201648.AA19486@newsu.shearson.com>
Message-ID: <9211230949.AA13573@shadow.cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain


   >I wonder--I have RSA Mailsafe.  Do you think that would give me a license
   >to use RSA if I loaded up PGP?  Keith

   Doubtful -- RSA tends to be licensed on a per application per copy
   basis, not on a per human basis. If it was licensed on a per-human
   basis, I would have bought a personal "unlimited use" license long ago.

Well, they sell licenses for RC2 and RC4 for $100 per, which are on a
per-person basis.  And something said to me at Weenix Expo by an RSA
salesdroid implied that $100 could get one a generic kind of RSA license.
I didn't press the point, and I don't have anything in writing, but
they're happy to talk at 415.595.8782 if you want better than
unsubstantiated hearsay...

I'd call myself if I was ever awake during PST business hours...

andrew




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Mon, 23 Nov 92 12:17:13 PST
To: crunch@netcom.com
Subject: re: Status on Mac PGP
In-Reply-To: <9211231013.AA10065@netcom2.netcom.com>
Message-ID: <9211232016.AA12371@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


>> short term team which no doubt will be what exists already,  and
	I assume you already know that a Mac PGP exists? I didn't
mention it before because the discussion seemed to be about doing a
"real" version.
	mac.archive.umich.edu:mac/util/encryption/macpgp2.0.sit.hqx 
is the path. It is still there right now...
				_Mark_ <eichin@athena.mit.edu>
				<eichin@cygnus.com>
% ftp mac.archive.umich.edu
Connected to mac.archive.umich.edu.
220-  
220-  Welcome to  
220-  the U of M Software Archives
220-
220-
220 carpediem.ccs.itd.umich.edu FTP server (Version 6.9 Thu Oct 15 23:44:46 EDT 1992) ready.
Name (mac.archive.umich.edu:eichin): ftp
331 Guest login ok, send e-mail address as password.
Password:
230-Please read the file 00readme.txt
230-  it was last modified on Tue Nov 17 22:08:12 1992 - 6 days ago
230 Guest login ok, access restrictions apply.
ftp> cd mac
250- 
250-Please read the files in /mac/00help if you have problems.
250-
250 CWD command successful.
ftp> cd util
250 CWD command successful.
ftp> cd encryption
250 CWD command successful.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 364
drwxrwxr-x  2 20020    staff        2048 Dec 31  1991 .AppleDouble
-rw-rw-r--  1 25319    staff       54788 Oct 13 05:42 crypto1.23.cpt.hqx
-rw-rw-r--  1 20062    staff       19987 Feb  6  1991 des.hqx
-rw-rw-r--  1 25319    staff       56824 Nov 14 08:55 enigma1.1.sit.hqx
-rw-rw-r--  1 20062    staff       26227 Feb  1  1992 leescrypto1.2.cpt.hqx
-rw-rw-r--  1 23424    staff      210389 Oct 30 19:45 macpgp2.0.sit.hqx
226 Transfer complete.
439 bytes received in 0.21 seconds (2 Kbytes/s)
ftp> 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Wed, 25 Nov 92 03:28:55 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: SF Bay Area Parties
Message-ID: <muTPuB9w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


Distribution:
   Cypherpunks          <cypherpunks@toad.com>
   Extropians           <extropians@gnu.ai.mit.edu>
   Libernet             <libernet@dartmouth.edu>
 
Since all the above groups, of which I am a member, are not known
for sponsoring social functions, I suggest we co-opt the Pen SFA
parties.  Their latest "Winnie" newsletter is attached. Please note
and follow "rules".  I especially recommend the 12/26 party.
 
PGPers, bring your printed public keys for exchange.
 
If you like these parties, please sign up for free E-Mail distribution
of your own copy of the newsletter, as I will not post it every month.
=================Copy of Newsletter follows==========================
Date: Sat, 21 Nov 92 12:51:33 PST
Subject: Winnie the POO #380
 
Winnie the POO #380, November 21, 1992
 
Published for the Peninsula Science Fantasy Association by its
commander, Rich McAllister, 149 Webster St, Palo Alto, CA 94301.
(415)328-2741.  rfm@Eng.Sun.com.
 
Winnies are available by US Mail at 5/$2, or via electronic mail
(Internet/UUCP/CompuServe/FIDONET) free.  If you're mailing payment make
checks to Rich McAllister, or send stamps. I prefer stamps, so I'll give
you one issue for each 29 cent stamp you send, and eat the repro cost
myself.  The number above your name on the label is the number of the
last Winnie you will receive unless you Do Something.  A 999 means you
get Winnie by trade.
 
PenSFA standard party rules: bring something edible or drinkable to
share, or pay the host $2.  Don't smoke in the house without checking
with the host first.  Normal start time is 8PM.
 
NO SECOND NOVEMBER MEETING (11/28)
 
We will not have a second November meeting because of Silicon.  NOTE:
SILICON IS NOT AT THE RED LION!  (This seems to be a well kept
secret.)  Silicon is at the Westin Santa Clara.  This is the hotel
between Techmart and the Santa Clara Convention Center.  (It used to
be the Doubletree.) Take the Great America Parkway exit from 101, go
past Great America; as soon as you cross the trolley tracks, you're
there.  Friday, Saturday, and Sunday.  I probably won't be there to
organize a PenSFA event.  I suggest interested folks meet at 6PM
Saturday in the lobby for a dinner expedition.
 
FIRST DECEMBER MEETING (12/12)
 
Party at Danny Low's, 1460 San Marcos Circle, Mtn. View.  (415)964-0688.
Standard time, 8PM, standard rules.  Easy to find with a map.
 
SECOND DECEMBER MEETING (12/26)
 
Potluck at the home of Keith Henson and Arel Lucas, 1794 Cardel Way,
San Jose, CA.  (408)978-7616. 5PM start.  Standard party/potluck
rules: bring dinner and munchies/drinks if you come early, or just
munchies/drinks if you come at 8PM. Keith offered to fire up the BBQ,
weather permitting, but I wouldn't count on it.
 
NEW DIRECTIONS (road construction has made the old directions
obsolete.)  Directions: From 280, take 17 south to Camden Ave exit.
Go under freeway, follow Camden east. Turn south from Camden on Leigh,
go two lights south to Los Gatos Almaden road, left and almost to
where it ends in a T is Elrose.  Left onto Elrose and another
immediate left onto Cardel Way.  We are near the end at 1794.
 
NOT A DECEMBER MEETING (12/31)
 
Mike Ward is having a New Year's party again, and again all PenSFAns
are invited. 1181 Martin Drive, San Jose.  408-298-3269.
 
 
Future Meetings: NOTHING SCHEDULED until 3/6-MIke Ward. As always,
contact the Commander to take a date.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Mon, 23 Nov 92 14:40:40 PST
To: cypherpunks@toad.com
Subject: Re: Hackers, Crackers
Message-ID: <9211232221.AB05926@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


>Let's cut out this elitist "crackers" crap altogether.  
>It's just a little bit too PlaySkool, a little bit too 
>"_I'm_ not a third grader!  I'm a _fourth grader_!"  The people
>who put so much energy into advertising how they're different
>tend not to know what the fuck they're talking about, in 
>my experience.

Well, I don't know about this guy, but there's something similar that 
occurred to me during the hackers conference.  Some of the people on this
list heard me express it badly, and I wanted to clarify.

We always used to distinguish hackers from crackers.
But cracking reveals the cracks in a way that nothing else does.  
It makes them real, sometimes laughably or painfully so.
Electronic privacy is currently a joke.  It's bad.
You need to know what kinds of attacks you're trying to defend against.
I used to think those arguments were rationalizations.  
Now I'm glad there are people who know this stuff, who are actually doing it.
Some of "them" are on what I think of as the good side, and "we" need that
kind of knowledge, if only as an occasional splash of cold water, a spur
(to switch metaphorical, er, horses in mid, um, stream).

-fnerd
quote me
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 24 Nov 92 11:58:48 PST
To: cypherpunks@toad.com
Subject: Scenario for a Ban on Cash Transactions
Message-ID: <9211241954.AA17648@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks of the World,

I'm relatively convinced that the various "trial balloons" for
restricting the use of encryption are part and parcel of a larger,
albeit not formally discussed, plan to adopt some form of a digital
cash system. Before your start cheering, it is highly unlikely that
this system will the "digital cash" system of the form we have been
discussing (anonymous transactions, untraceability, David Chaum-style
systems, etc.). 

My grim scenario is contained in the message below, which I just
posted to another list, the "Extropians" list.

--Tim May


Forwarded message:



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay (Timothy C. May)
Date: Tue, 24 Nov 92 11:44:08 PST
To: extropians@gnu.ai.mit.edu
Subject: Scenario for a Ban on Cash Transactions
Message-ID: <9211241944.AA16548@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


SCENARIO FOR A BAN ON CASH TRANSACTIONS

The recent discussions about black markets, loss of tax revenues, and
restrictions on the use of encryption lead me to speculate that moves
may be afoot to ban or severely restrict the use of cash.

Such talk of a "cashless society" comes up periodically, with some
taking a religious/conspiratorial view (electronic bank accounts
tatooed on our foreheads, fulfilling the "mark of the Beast" prophecy)
and others talking about how the "international bankers" have already
selected a system (to be implemented in a national emergency, perhaps
an Emergency Order following a series of bank collapses).


Some putative benefits of banning cash and replacing it with
electronic versions (such as debit cards, either privately issued or
issued by the government):

1. Faster and more complete tax collection, with the tax authorities
and implicit partner in all economic transactions (save for black
markets, but I'll discuss that later).

The "faster" part will be a one-shot gain, just as the witholding tax
system instituted in WWII as an emergency program was a one-shot
benefit. But such an immediate gain may be quite attractive to
planners faced with rapidly escalating national debt. ($4.5 trillion,
increasing by at least $400 billion a year...more if the "IOUs" for
social security are considered)

The "more complete" part will be an attempt to recapture taxes now
lost to the underground, or barter, economy. "Serious" black
marketeers, or dealers in illegal substances, will of course not be
greatly affected, but a shift to purely electronic money will hurt
their ability to move money (unless they control the banks and S&Ls,
as may be the case....but that's another story).

2. A general closing of the underground economy, separate from the
issue of recapturing lost tax revenues. As the underground economy
increases, especially to the levels seen in other countries, pressures
to "close the loopholes" (= cash) may mount. The failing "War on
Drugs" has already been used to justify many serious abridgements of
basic rights; applying the same logic to creating a cashless society
seems to be the next step.

3. "Welfare reform" by restricting the allowable expenditures that can
be made. For example, a welfare, food stamp, or AFDC recipient could
be barred from buying liquor with his or her "money." Electronic money
need not be "fungible," in the sense that all forms are
interchangeable--it is fairly easy to attach various restrictions to
the electronic databases which hold the money.

Such restrictions would meet with a lot of popular support, and so
could undercut the protests a bit. (Support may also come from the
"national identity card" aspects, as such a card would help to solve
the problem of illegal immigrants and those who move to jurisdictions
with better welfare benefits. I'm not _approving_ of this, merely
pointing out a source of support for "welfare cards.")

(Bypasses can still be done, as with food stamps which are sold in
exchange for booze. Ironically, the flourishing black market in food
stamps is a motivation for going to an "electronic welfare card,"
which is being talked about and which is an obvious precursor step to
the eventual ban on paper money cash.)

4. Fears of the growing ease of counterfeiting may push this shift
along. Color copiers are now so good that nearly undetectable
counterfeiting of U.S. currency is straightforward. Attempts to embed
conductive threads, holograms, etc., are helping, but the longterm
future is not bright for physical money (excluding gold, which has its
own problems that I won't discuss here).

(Note that foreign printing presses can quite easily produce excellent
counterfeit currency, for use in destabilizing foreign regimes, in
economic warfare, etc. Apparently the U.S. has supported the flooding
of Iraq with counterfeit currency. And Iraq has supposedly printed
vast amounts of counterfeit U.S. and European currency. Digital money,
cryptographically protected, is about the only protection against this
threat.)

5. If the government controls and sets the protocols for electronic
money, this gives them de facto control over encryption systems and
protocols.  Use of non-approved protocols may be considered ipso facto
proof of money laundering, black marketeering, and tax evasion.

The Dennning/Rivest key registration proposal appears to be some
advance planning for creating a system in which the government is
effectively a third party in all communications (= transactions). 

I suggest we look at all such key registration proposals in this light.

6. More speculatively, the elimination of cash may be used to prop up
U.S. banks, which many feel are facing a rocky future. By making the
banks the "mediators" of such a government-mandated electronic money
system, this both "privatizes" the system and provides a new revenue
stream for these powerful lobbying interests. For example, your local
bank may issue the debit card and may take, say, 0.5% of every
transaction. The government might then take, say, 3% of every
transaction as its "cut." (The actual details are likely to be
hideously complex, along the lines of the V.A.T. taxes of Europe, and
so this example should only be taken as a rough example of what could
happen.)


Now it has long been clear to me that the future of money lies in
electronic form, cryptographically protected. The prolific use of
credit cards for mail-order purchases points to the need for a purely
electronic form of usable money, as do systems like AMIX (which uses
VISA-type credits and debits). The issue is who creates this system,
and what controls exist.

It seems unlikely that the U.S. government will allow "competing
currencies" (one form of digital money, and arguably what we already
have with various tradable financial instruments, which rise and fall
in value depending on various forces) to spring into being, at least
not in forms that are truly like cash.

However, if the government creates this cashless society, then the government
will have unprecedented control over nearly all aspects of our lives.
All transactions, no matter how trivial, will be recorded, stored, and
subject to analysis. A complete audit trail of all purchases, food
preferences, entertainment choices, liasons with others, etc., will
exist. This is the concern David Chaum has eloquently raised, and
which he has been dealing with (partially) with his digital money and
untraceable transactions systems.

Furthermore, transactions which are deemed to be politically
incorrect, and there are dozens of obvious examples to choose from,
can be _outlawed_ by the mere typing of a few lines of instructions into
the appropriate data bases. (For example, someone arrested for DUI
tries to buy some beer..."Your transaction cannot be completed. Have a
nice day."  appears on the cash register. Or a pregnant woman--and
under Clinton's computerized health care system this will all be
known--tries to buy some cigarettes....)

Reread John Brunner's amazingly prescient "Shockwave Rider" for some
visions of a fully-computerized society.

This trend toward a cashless society, controlled by the government,
represents the greatest threat to our libery and our future I can
imagine.

We need to start planning to head this off. Those interested in
"crypto anarchy" as one technological solution are encourage to get in
touch with me.

(I now have MacPGP, which makes things slightly easier than before,
but it's still a pain to download files and decrypt them. The
anonymous remailer services discussed on the "Cypherpunks" list should
help as well.)

Make no mistake, a government-run cashless society will be worse that
Orwell's worst.

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Tue, 24 Nov 92 11:06:50 PST
To: cypherpunks@toad.com
Subject: Remailer ideas
Message-ID: <9211241849.AB05399@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


Tom.Jennings@f111.n125.z1.FIDONET.ORG sez

>Well, remailers are working, admittedly a bit clunky at the moment,

Okay, here's something easy to implement: a "From: stripper" specifically
for the cypherpunks address, like, 
        cypherpunks-anon@toad.com .

The point is that all you have to do to use it is to have the address.
The same for the following ideas:

Harder: something that takes mail to arbitrary "user ids" at its machine and
remails based on them, so you could send to me at, say,
        sw%%smds.com@remailer.somewhere.com .

Harder: take a long encrypted address as the user id.  Do mail systems
allow arbitrary length user ids?  Anyway, you'd be mailing to things like:
        wjefa248hap94ghs39p8g4s9perspe98b9p08serhg9p8serh9sherp9hse9rp89sper898psexrg99p8ser989regp9ser9pys98per9pse8ry9p8sxyer9p8yser9p8ys9per8p9se8ry9pseyr8sezrpahw4pwa49nw84th9w8y34w456yuvw05536vue4w5vw38064vw306uw45@remailer.somewhere.com

I realize these things have weaknesses beyond the kazoo, but wadaya think?

-fnerd


fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: julian@panix.com (Julian Dibbell)
Date: Tue, 24 Nov 92 13:47:22 PST
To: cypherpunks@toad.com
Subject: Mailing-list
Message-ID: <9211242017.AA21820@panix.com>
MIME-Version: 1.0
Content-Type: text/plain


Can you add me to the cypherpunks mailing list?

--Julian Dibbell, julian@panix.com
(Steven Levy and/or Tim May may [or may not] vouch for my worthiness,
as necessary)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Fan Li TAI <UFLTAI%MEMSTVX1.bitnet@CUNYVM.CUNY.EDU>
Date: Tue, 24 Nov 92 14:57:29 PST
To: cypherpunks@toad.com
Subject: Question about the MacPGP
Message-ID: <9211242257.AA21968@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Hiya,
        About the MacPGP, isn't it possible to sort of write a script addon
to the various telecoms software?  What I mean is that when you start reading
mail, you click somewhere, and all input from the modem is translated direct
by the script so that you can read the plaintext.  But when you reply, you will
have to use the telecoms' editor and upload the text...
        Somewhat like that rot13 thing in news really (or the VMS implemantation
of it).
     Ciao.

-Tai




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dkrieger@netcom.com (David Krieger)
Date: Tue, 24 Nov 92 17:01:11 PST
To: crunch@netcom.com (John Draper)
Subject: One Mac feature I'd like
Message-ID: <9211250057.AA08182@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


John --

While using MacPGP yesterday, I thought of a useful feature that (I
hope) wouldn't be too hard to implement -- the ability to encrypt to/
decrypt from the Clipboard.  This would eliminate the need for saving
one's text as a file in order to use PGP... one could Copy text from
any text application, open PGP, encrypt it in the Clipboard, and switch
to a terminal program to Paste it to a host for mailing... or, one
could Copy ciphertext from the terminal program and decrypt it from
the Clipboard.
					dk
-- 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 24 Nov 92 17:54:15 PST
To: cypherpunks@toad.com
Subject: The List is YOURS, So Speak Up!
Message-ID: <9211250150.AA12171@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Lurking Cypherpunks,

My message earlier today on a scenario for the banning of cash led to
about 10 responses mailed to me in private e-mail. Typical is the
following (the author has been deleted, as he chose not to post it to
the list as a whole):

"I'm interested.  I was considering removing myself from the cyberpunks
list, because the traffic/info. ratio is too high (low?)..  I'm glad I
didn't, because your message is the type of thing I joined the list to
read.  I don't suppose there somewhere where I can get a 'condensed
version' of the cyberpunks list, or something similar?
      
"I've heard a bit about "crypto anarchy" (only from cyberpunks mailing
list), and i'm interested.  What's the next step?"


You folks out there ARE the list! If there's something you want
discussed, go ahead and start a new thread. Raise some issues, stir up
some shit.

It seems from some of the messages I got today that people think they
either have little to add to the discussion, or are fearful of the
consequences of posting their comments to a list such as ours.

About the former point, all I can say is that the best learning comes
from arguing a position and learning to defend it. Merely _posting_ a
message generates added interest and piquancy about the list, I've
discovered.

So consider this an invitation to the hundred or so folks who have yet
to post on this list!

For those who are paranoid, well, chances are They already know who
you are. They have files on you.

Remember this,

* It is not illegal to advocate violence.

AND

* it is not illegal to advocate the overthrow of the government.

HOWEVER,

* it _is_ illegal to advocate the overthrow of the government by
violent means.

If you stay away from this last item, you're relatively safe. (Even
advocating drug use has not seemed to have much effect on the posters
on alt.drugs.)

In any case, the work being done by Eric Hughes, Hal Finney, and
others, should give us fully anonymous posting capabilitites in the
near future. Even with digital pseudonyms! (Check out the postings of
"Cassandra" and "Pollyanna" for starters.)

If the socioeconomic aspects of crypto anarchy interest you more than,
say, discussions of random number generators, then clearly you should
_post_ on those topics!

And if all you have are _questions_, then by all means ask them! Those
of us who post frequently on this list cannot try to anticipate your
questions and concerns.

I've been spouting this stuff for years and they haven't taken me away
yet, nor have they



[TRANSMISSION HALTED BY ORDER OF THE CRYPTO AUTHORITY]
 
      

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 24 Nov 92 18:24:38 PST
To: cypherpunks@toad.com
Subject: Re: DC-NETS & bibliography request
In-Reply-To: <9211250202.AA11244@tweedledumber.cygnus.com>
Message-ID: <9211250220.AA14681@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Reading Material:

> This list is the first place I'd seen references to DC-NETS; thanks
> for the glossary posting explaining what the term is. Is there a
> published paper on them, or somewhere else I can get info on the
> algorithms involved?
> 	On a related note, is there a "crypto anarchy reading list" or
> bibliography that anyone has collected, for further delving into the
> terms brought up? I suspect many of the better references would only
> be available in electronic form, but they should still be listed...
> 
> 				_Mark_ <eichin@athena.mit.edu>
> 				MIT Student Information Processing Board
> 				Cygnus Support <eichin@cygnus.com>

The article I posted, and the article Hal Finney posted, contains
references to the original DC-Net paper. It was in the Journal of
Cryptology, Volume I, Number 1. Only a very large university library
will carry it. (My nearest university, UC Santa Cruz, does _not_. I
subscribed for a while, because of attending the Crypto '88
conference, and so I was able to include this seminal paper in the
Xeroxed handout for the attendees at our first Cypherpunks meeting. I
regret that I cannot mail anymore copies to people. If you are really
interested in DC-Nets, read the posted articles first and then you'll
surely find a way to get the journal articles.)

The standard sources for modrern crypto are the proceedings each year
of the "Crypto" and "EuroCrypt" conferences. Also, at least half a
dozen good books have been written, some of which have been mentioned
in earlier postings.

And Fen Le Balme posted his won search list a few weeks ago. At some
point an FAQ and bibliography list will exist (I am not maintaing the
FAQ or the bibio, though).

Here's a typical reference:

16. CRYPTO '91 (1991 : University of California, Santa Barbara)
Advances in cryptology--CRYPTO '91 : proceedings / J. Feigenbaum
(ed.).  
    Berlin ; New York : Springer-Verlag, c1992.                 
      Series title:  Lecture notes in computer science ; 576.   
        UCB   Engin     QA76.9.A25 C79 1991                     
        UCD   Phys Sci  QA267.A1 L43 no.576                     
        UCI   Main Lib  QA76.9.A25 C79 1991                     
        UCLA  Engr/Math QA 76.9 A25 C79 1991                    
        UCR   Rivera    QA76.9.A25 C79 1991          
        UCSB  Library   QA76.9.A25 C79 1991 Sci-Engrg           
        UCSC  Science   QA76.9.A25C79 1991                      
        UCSD  S & E     QA76.9.A25 C79 1991                     

The books in the "QA76.9.A25" section (Library of Congress numbering
of course) will provide pointers.

Sadly, there are no "Neat Crypto Ideas for the Casually Interested"
books. Some of us have debated writing such a book for Loompanics
Press.

--Tim May

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Tue, 24 Nov 92 19:03:37 PST
To: uunet!smds.com!fnerd@uunet.UU.NET
Subject: Hackers, Crackers We always used to distinguish hackers from crackers. But cracking reveals the cracks in a way that nothing else does.   It makes them real, sometimes laughably or painfully so. Electronic privacy is currently a joke.  It's bad. You need to know what kinds of attacks you're trying to defend against. I used to think those arguments were rationalizations.   Now I'm glad there are people who know this stuff, who are actually doing it. Some of "them" are on what I think of as the good side, and "we" need that kind of knowledge, if only as an occasional splash of cold water, a spur (to switch metaphorical, er, horses in mid, um, stream).
In-Reply-To: <9211232221.AB05926@smds.com>
Message-ID: <9211250220.AA26816@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


And if I shoot you or poison you, I will have vividly revealed to you
your pathetic lack of physical defenses.  Will I have done you a
service?  How about if I just break your windows or doors?

That rationalization for crackers is based on the idea that perfect
security is feasible.  Once you view this from an economic
perspective, then the only things the crackers do is raise the
cost of getting to a level of security such that operation can
continue uninterrupted.

BTW:  I happen to believe that within a trusted infrastructure,
perfect security is possible.  Even so, consider the cost of changing
operating systems, retraining all staff, reproducing familiar
applications on a new substrate.  Even if perfect security is
possible, the use of it is still bounded by economic and social
concerns.

dean

BTW:  feel free to forward to extropians.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Tue, 24 Nov 92 19:03:37 PST
To: uunet!smds.com!fnerd@uunet.UU.NET
Subject: Remailer ideas
In-Reply-To: <9211241849.AB05399@smds.com>
Message-ID: <9211250223.AA26837@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


The mail handling stuff we discussed at the last cypherpunks meeting
will implement what you requested.  The particular thing that hadn't
occurred to me in what you said is that a mailing list supplier could
provide those extra services of anonymity in a way very accessible to
users of the mailing list.  That could make such anonymity slightly
easier to spread.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Tue, 24 Nov 92 18:02:57 PST
To: cypherpunks@toad.com
Subject: DC-NETS & bibliography request
Message-ID: <9211250202.AA11244@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


This list is the first place I'd seen references to DC-NETS; thanks
for the glossary posting explaining what the term is. Is there a
published paper on them, or somewhere else I can get info on the
algorithms involved?
	On a related note, is there a "crypto anarchy reading list" or
bibliography that anyone has collected, for further delving into the
terms brought up? I suspect many of the better references would only
be available in electronic form, but they should still be listed...

				_Mark_ <eichin@athena.mit.edu>
				MIT Student Information Processing Board
				Cygnus Support <eichin@cygnus.com>




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 24 Nov 92 21:12:15 PST
To: cypherpunks@toad.com
Subject: An Anonymous Contribution...
Message-ID: <9211250508.AA01456@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


(The following message arrive in my mailbox, with a request to repost
it anonymously. Sometimes these "manual" methods work pretty well!
--Tim May)


Tim,
	I have been following your arguments in CypherPunks.

The name will turn off a lot of your natural friends, but your arguments are
dead on.  The Crux of the matter is digital cash.  And getting
these anonymous remailers working.  PGP is a basic enabling
thing.  Not that RSA hasn't been around forever, but it
just wasn't useable without a standard.  My deepest gratitude
to you and your friends.

The remailer business needs to get standardized also.  My personal
hack is attached below.  One problem not addressed in the first
crop of remailers is the problem of how do you handle return
paths.  There are lots of trivial ways to get anonymous outgoing
mail. Most telephone systems do not identify the caller, there are
lots of other ways to get this function.  But the problem is getting
an answer back with out unmasking.  The mathematicians may be able to
conjure up a better scheme, but I see the backward security to be
simply a matter of tearing the connection (return path down) faster
than it can be backtraced.  It would be nicer if some kind of
DC-net return path could be devised.  But timeout control will 
definitely work. With a large number of the forwaring nodes, and
multi-hop paths, it would become quickly very impractical to shake
down the originator,  So the return path could be left "up" for 
quite some time before having to replace it.  Certainly long enough
for a reasonable reply.  Better yet of cource would be a completely
uncrackable return path that you could leave up long enough to use
institutional advertising.  Eg: run a business from.

Another way to leave up long lasting connections (return paths)
is to select one really HARD point node.  This is the one they
have to shake down first.  And use continuously shifting paths
behind that node.  (all sounds like a router ? ) 

If you could repost this anonymously
I sure would appreciate it.  I am  (ahem, respectable), and have
some kids left to feed. 

Could you tell me how to find out more about David Chaum's work?

do you have an email address for him, is he on one of the mailers,
or have anything published?

My hunch is that this whole business could heat up fast.  Within just a
few years the government could be forced into "wage/price" controls.
A great application for the NREN?

Thanks,  xxxxxxxx@yyyyyy.zzz

---------Tear off  -----

This is a proposal for a simple anonymous forwarding protocol.

1>  With the exception of cases 4> and 5> below:

    Any message addressed to the forwarding node that does not
    contain a valid PGP encrypted block, encrypted with the 
    node's public key causes the forwarding node to reply to
    the sender with its public key, plus whatever other 
    text the node wishes to add.

2>  If a properly encrypted message is decrypted with the node's
    secret key; The body of the decrypted message is scanned
    for the following sequence:

    "Please forward this message to:"  FORWARD.ADDRESS  "Thank you."

    The trigger strings are what is shown above in the quote marks
    but not including the quote marks.  No actual quote marks are used.

    Everything after the period of the Thank you. string is forwarded
    to the address specified by the FORWARD.ADDRESS string.

    Messages not containing the forwarding request are presumed
    to be addressed to the node itself.

3>  The incoming RETURN.ADDRESS and the FORWARD.ADDRESS are stored
    by the node.

---- Clean up.

4>  Receipt of a message whose RETURN.ADDRESS matches a stored
    FORWARD.ADDRESS will be repeated without modification
    to the stored RETURN.ADDRESS associated with the stored FORWARD.
    ADDRESS.  Bounced mail is returned similarly, 

5>  Receipt of a message whose RETURN.ADDRESS matches a previously
    stored RETURN.ADDRESS will cause a message to be
    forwarded to the previously stored FORWARD.ADDRESS 

    If the incomming message in this case contains a valid encrypted
    block, It will be decrypted and forwarded.  Otherwise, whatever
    contents of the body found will be forwarded.

    Subject lines should be repeated without modification.

    Null bodies or subject lines should work.

6>  In both cases 4> and 5>, the stored RETURN/FORWARD
    addresses are erased.

-xxxxxxx



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.
















From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bob Stratton <strat@intercon.com>
Date: Tue, 24 Nov 92 18:16:51 PST
To: cypherpunks@toad.com
Subject: Re: The List is YOURS, So Speak Up!
Message-ID: <9211242116.AA28432@horton.intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


Hi all,

After Tim's stirring message about the use of the list, I couldn't help but 
drop a line to the list myself.

I'm yet another person interested in Mac implementations of PGP, and 
encrypted mailers. I work for a Macintosh software company as a developer, 
but have spent most of the last several years working with big machines, so I 
haven't picked up all of the bad habits that I see Macs furthering across the 
Net. (Most of these have to do with writing unportable code, as if no other 
manufacturers' hardware matters.)

I'm also sort a mailer weenie, so this talk of encrypted mailers has me quite 
interested. I've started studying more of the fundamentals (I've only read 
David Kahn's book, back in 8th grade, which was a while ago :-) I'm 
especially interested in the MIME/PEM issues, and fervently request coredumps 
from anyone who's been following those to date. 

My company (which I DO NOT speak for) develops TCP/IP based communications 
software for the Mac, so needless to say, a nice RSA-encrypted Mac mailer 
could fall within our purview. My company is also very interested in privacy 
issues. In point of fact, the VP of Engineering and I recently addressed a 
Virginia state assembly subcommittee for purposes of having them remove SSNs 
from driver's licenses.. (YAY!)

I'm new to tbe Mac world, but not the mailer world. I shall try to be a 
resource for this list's work. There's another person here who's also 
interested in the GUI design for a new Mac incarnation of PGP. 

I see a couple of possible UI features:

 - Live folders, for drag and drop en/decryption

 - Encryption to/from the clipboard (which is basically what I'm doing now, 
	except through intermediate files)

 - An  MPW tool implementation, with pipes. (I suspect that I'd use this 
	mostly for testing the 'engines')

I want to reiterate the sentiment posted by several to KEEP THINGS PORTABLE. 
I know it's not chic for a Mac developer to say that, but so be it.

Bob Stratton     Engineer, InterCon Systems Corp.     <strat@intercon.com>
+1 703 709 5525
"The Constitution's not perfect, but it's a damn sight better than what we 
have now."







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Tue, 24 Nov 92 22:12:47 PST
To: cypherpunks@toad.com
Subject: Re: Extortion Explosion
Message-ID: <9211250614.AA17663@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


Here's another thought about how crypto anonymity can improve
public safety.

Today, a lot of police activity is based on informants and "anonymous"
tips.  Policemen build up relationships with underworld characters
who can give them information about criminal activity.  In return,
the police may offer favors, immunity from arrest, perhaps even
cash or contraband in some instances.

Some people have claimed that "anonymous sources" are an excuse sometimes
used to cover up illegal police activity.  An illegal wiretap is used
to acquire information, then a warrant is obtained based on this
information with the claim that it was actually acquired through
an anonymous informant.  With the warrant in place, the wiretap is now
done legally, and evidence is produced which can be used in court.

One problem with anonymous tips is that the people making them are
taking a risk.  If word gets out that a certain person tipped off
the police to some criminal act, they may be targetted for revenge.
Personal meetings between police and informers are often necessary
(perhaps for payoffs to occur) and these are risky for all involved.

Crypto anonymity could make anonymous informing easy and safe.  Of
course, not all tips would be valuable, but some fraction would be
helpful in preventing crimes.  Crypto pseudonyms and signatures could
be used for informants to develop reputations so that those who have
been accurate in the past will get the most attention.  Digital cash
could even be used for payoffs from cops to informants "under the
table", with no need for dangerous face-to-face meetings.

A system could even develop in which police would have to bring to
a judge not just a blanket claim that there was an anonymous informant,
but more substantial evidence, in the form of a digitally signed statement
by a pseudonym known to have produced useful information in the past.
This could reduce the problem of imaginary informants invented to
excuse illegal police activity.

Polyanna 

-----BEGIN PGP PUBLIC KEY BLOCK-----
mQA9AisGm6sAAAEBgLsub7XIi32DjNFKJmGFajDNNIeql4RBmHG/mh9Ns58aBgMv
wGRi0KkZ0YIYZZnLpwAFEbQkUG9seWFubmEsIGMvbyA8Y3lwaGVycHVua3NAdG9h
ZC5jb20+
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: DELTORTO@AppleLink.Apple.COM (Imaja, David Del Torto,PAS)
Date: Tue, 24 Nov 92 16:36:01 PST
To: CYPHERPUNKS@TOAD.COM
Subject: virgin key
Message-ID: <722650089.8392816@AppleLink.Apple.COM>
MIME-Version: 1.0
Content-Type: text/plain


Greetings CypherFolk,
 
I'm still in Europe, researching combinations of sleep deprivation and extended
train travel, but the time for return to sf.ca.us is drawing closer. I'm still
temporarily off the c-punks mail alias due to technical/fiscal reasons so buzz
me directly at <deltorto@applelink.apple.com> until January 93.
 
Appended below is my brand-spankin'-new 512-bit public key. Give it a workout
so I can see if it works (out). I have an interesting keyring from over here if
anyone is interested. Will attend meeting anytime in '93 if I'm notified so we
can pass the baton -er- floppy.
 
   dave del torto
 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0
 
mQBNAisMWqcAAAECALhs0wMpfVaVFIP/pk3MouI7X8sqpbB6eKiCoVPWBAOeMhB3
bOE8gibIgx5Gg+yTTmp5WOBXzmqmN8s2NPwzoIMABRG0LkRhdmlkIERlbCBUb3J0
byA8ZGVsdG9ydG9AYXBwbGVsaW5rLmFwcGxlLmNvbT4=
=cnh0
-----END PGP PUBLIC KEY-----
 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Wed, 25 Nov 92 01:24:26 PST
To: tcmay@netcom.com
Subject: Re:  Scenario for a Ban on Cash Transactions
Message-ID: <199211250923.AA21269@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Tim refers to Brunner's Shockwave Rider as "amazingly prescient."

As he says of Brunner's diagnosis, so say I of Brunner's prescription.

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Wed, 25 Nov 92 02:03:52 PST
To: cypherpunks@toad.com
Subject: Re:  Question about the MacPGP
Message-ID: <199211251002.AA24840@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



re Tai's item about more user-friendly decryption on the Mac version....

Seems to me we need it for encryption as well...  For instance, telecom
software which allows you to back out into a screen editor where you write
something and then encrypt it, and then get back to telecom and transmit the
ciphertext directly.  In my use of email, spontaneous mail and replies are
vital.  Having to go offline, go into WP, compose, go to crypto and encrypt,
then go back to telecom, link up again, and transmit.... Holy cow, if that
were a prescription for safe sex, it would be "Start a romantic evening.
Just when you and your Love are sitting by the fire holding hands, get in
the car, go to the drugstore and buy condoms.  Then come back to where
you've left your Love waiting by the fireplace, and try to get back in the
romantic mood.  Then before bedtime, walk around the house to make sure all
the lights are off and the oven is off and the dog is in and the cat is out.
Then retire for the night, and try to get the romantic mood going again,
hoping that your Love hasn't fallen asleep while you were making your
rounds..."  Eee-yow, we can do better than that!

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 24 Nov 92 23:13:08 PST
To: cypherpunks@toad.com (CypherPunks Mailing List)
Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology)
Message-ID: <9211250712.AA03659@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


A very useful device for people who can not trust the host they are
talking to such as users of multiuser unix systems, or low security BBS
systems, or "public access" workstations or PC-s, (this includes almost
every single person that uses e-mail, except probably for users of a
high-security mainframe communications system) would be an RS232 crypto
"dongle" that would sit between the terminal (or modem) and the remote
system.

It would contain some tamperproof (write and decrypt only, can not be
read out without a great deal of trouble) memory (as someone at the
midnight crypto session at Hackers was talking about) for storage of
the private key, some nonvolatile memory (flash eprom?) for the public
key ring, and a processor to do the encryption/decryption.

It would look (if all that can be fit into a small enough space) like a
null modem or a gender changer.  (or an RS232 break-out box). If crypto
tech ever becomes illegal, it could even be disguised as one, with some
special signal combination enabling the crypto function.

It should also contain some out-of-band signal such as an LED to
indicate that it is actually doing the decryption, instead of the host
mimicking it.

If introduced now or in near future, this device could become
incredibly widespread, since most everybody that is accessing any form
of e-mail goes at some point through an RS-232 link (either a terminal
hanging off a terminal server, or a PC connected to a modem).

Also, it would not require ANY special software on the host or the pc,
nor any special terminal.  Thus it would work with any of the great
variety of e-mail and BBS sysetems that exist, instead of having to
deal with each of them individually as a purely software-based approach
would have to.  It would also be completely independent of the type of
computer/terminal or operating system used.

You would send the usual mail command to the host, type the magic
sequence to the encryption device (or even better, flip a little
switch), and then type your message.  The device would send to the host
the ciphertext, while echoing the plaintext to your terminal so you can
see what you are typing.  The plaintext would never travel further than
the RS232 connection between your terminal and the encryption device.

When you receive an encrypted message, flip the switch on your device
to "decrypt", and tell the host to send you the message.  The host and
any intervening networks would only see the ciphertext.  The only place
the decrypted text appears is on your terminal.  I think this is as
secure as you can get (until a decryption implant can be put in your
head :-).

Now, to allow the use of existing tools (pagers, editors, mailers, etc)
the device should be completely transparent except when performing the
crypto function.  Even then, careful design should make it pretty
transparent.  For example if it passed all control characters intact,
it could be used with a text editor that uses control key sequences for
movement.  It could be programmed for most common arrow key sequences,
and for commands for editors such as EMACS, vi, etc, to pass them
through unchanged.

Same thing for receiving. When decrypting, it should pass through
unchanged any characters passing through the other way, and should not
interfere with terminal control characters, so any mail viewing program
would not be affected.

Additional functions it might include are generation and verification
of signatures, an echo mode with decrypt/encrypt (so you could store
the encrypted texts on your local drive, and to view would just "ascii
upload" them to the device while in a comm program; also you could
prepare the text of a message locally, while storing the encrypted text
echoed back. Then you could upload the cyphertext to the system), a
simple local editor and viewer, and anything else we have the ROM space
for.  Once the basic hardware is developed, there is nothing to stop
one from including any desired features.

Is anyone here already working on something like this?  If not, is
anyone interested in working with me on developing this kind of a
device?  I have the design pretty much thought out (this post is just a
summary).  I also have a clear picture of the prototyping and
development process, and am capable of writing the software part.  I
would like to work with a partner who knows the hardware part of all
this.  I.E. the RS232/UART control, PCB layouts, that kind of stuff.
Also, I know almost nothing about the technology of tamperproof memory
storage.

The main objective of this is not to make loads of money (though that
would not hurt either) but to increase widespread accessibility and use
of good crypto technology.  So I would make the schematics and code
available, in case anyone wants to be SURE and build one themselves.
This could probably also be made available in kit form, that could be
assembled by the user.  (an interesting parrallel: this is how the
personal computer was first distributed... look at the prevalence of PC
use today!) This way they can be more sure that it does what it says it
does.

So, if you have read this far you are probably interested in this.
PLEASE reply to me or to the list.  If you are the person I am looking
for to help with the development, please contact me soon, using one of the
addresses or numbers listed in the signature. 

If you think you would be interested in buying or using such a device
when it is ready, please let me know.

If you have any improvements to the idea, or other comments, or reasons
why you think this device would not be useful or could not work, please
let me know too.

Waiting for your feedback....

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Wed, 25 Nov 92 02:21:46 PST
To: nobody@alumni.cco.caltech.edu
Subject: Re: Extortion Explosion
Message-ID: <199211251020.AA26264@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Polyanna's item about crypto-anonymity protecting informants and background
sources is most interesting.  DEspite my dislike of spying, this idea sounds
pretty decent.  No invasions of privacy or civil rights are necessarily
involved; infiltration is somehow not quite as awful as the spectre of mass
surveillance (if nothing else it's labor intensive, which limits its use to
substantial cases).  And it might just get a lot of results.  Might also
lead to a lot of whistle-blowing on white collar baddies like the S&L
fraudsters.  Hey, long before Michael Milliken's name was in the media, I
heard about his little fraud scheme from a fellow telecom technician who
worked on the PBX in his office and got a whole lot first-hand from casual
chat overheard in the office.  Consider all the secretaries who know their
bosses are cheating, ripping off, and all that.  (Consider them dead if
their crooked bosses ever go through the hard discs and find fragments of
cleartext or even ciphertext hanging about: we need to educate the public on
crypto protocol so people don't make dumb errors that may cost them dearly!)

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 24 Nov 92 23:33:02 PST
To: cypherpunks@toad.com
Subject: possibility of a reply to an anonymous message
In-Reply-To: <9211250508.AA01456@netcom.netcom.com>
Message-ID: <9211250732.AA03979@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> (The following message arrive in my mailbox, with a request to repost
> it anonymously. Sometimes these "manual" methods work pretty well!

If the person is not on the mailing list, please forward this to him/her/it?

> lots of other ways to get this function.  But the problem is getting
> an answer back with out unmasking.  

This is not difficult at all, it just costs bandwidth.  The basic idea
is to anonymously post or mail a message, and at the end attach a
public key, and the name of a public forum such as a usenet newsgroup.
Then whoever wants to reply, will encrypt the message with the public
key, and posts to the appropriate newsgroup.  No-one but the poster of
the original message can decrypt the reply.  since everyone receives
all the articles in the newsgroup, it is not possible to trace back who
decrypted the message.

> conjure up a better scheme, but I see the backward security to be
> simply a matter of tearing the connection (return path down) faster
> than it can be backtraced.  It would be nicer if some kind of

I would NOT rely on this under any conditions.  This could only provide 
enough security that someone who is NOT interested in you can not trace you.
Hey, for that kind of security you could use something like rot13...
Anyone that is in the least interested, will immediately investigate the
recent traffic at nodes the message went through.

> definitely work. With a large number of the forwaring nodes, and
> multi-hop paths, it would become quickly very impractical to shake
> down the originator,  So the return path could be left "up" for 

Unless someone really wants to.

> for a reasonable reply.  Better yet of cource would be a completely
> uncrackable return path that you could leave up long enough to use
> institutional advertising.  Eg: run a business from.

What I described above can work indefinitely (at least until your private
key is compromised)

> Another way to leave up long lasting connections (return paths)
> is to select one really HARD point node.  This is the one they

Again, I would not use this approach.  Such a node would become the target of
concentrated penetration efforts and would break down sooner or later, and
probably would remain operational, while logging all data.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 25 Nov 92 09:08:00 PST
To: cypherpunks@toad.com
Subject: The Cypherpunks Mail Project
In-Reply-To: <199211210833.AA19473@well.sf.ca.us>
Message-ID: <9211251705.AA17774@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I wrote:
>[...] there is no one place to push on the mail system to add encryption.

Let me explain.  You can push on a standard, but that doesn't change
any code.  If everybody in the world read mail with /bin/mail, then
you could rewrite that and add encryption.  What certainly is the case,
though, is that there are a lot of mail readers out there.

It is also the case that the cypherpunks, of all people, should be
using encrypted mailers.  Otherwise we are hypocrites.

Fen advocates MIME, and Ittai concurs.

Ittai asks, relating to existing MIME development work:
>Do we really want to give them an additional burden -- or do we want
>to leverage off work that is already being done?

It was my vision of this development that people here on the list
would do the work of integration and publish the results.

It is also my suspicion that simple PGP decryption support is fairly
straightforward, being mostly the ability to run a command on a block
and replace the block with the output of the pipe.  This model works
with regular mail and MIME, since it runs at the very top level of the
application.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 25 Nov 92 06:08:48 PST
To: Extropians@gnu.ai.mit.edu
Subject: Re: Private E-mail (re: Ban on cash transactions)
In-Reply-To: <9211251324.AA15058@wookumz.gnu.ai.mit.edu>
Message-ID: <9211251408.AA13799@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> I'm interested, especially if you'd be receptive to adding some
> capabilities beyond those you presently have in mind. For more info on

Yes, I am open to any suggestions.  

> these, see October Dr. Dobb's Journal, "What if there is a silver

I will definitely get it.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Wed, 25 Nov 92 02:54:15 PST
To: cypherpunks@toad.com
Subject: Re: How far is to far?
In-Reply-To: <199211211022.AA06269@well.sf.ca.us>
Message-ID: <1992Nov25.101452.11440@extropia.wimsey.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain


gg@well.sf.ca.us (George A. Gleason) writes:

>Miron writes, 
>"Charge for the mix services with crypto money.  The crypto money could be
>some networking service..."

>Only problem is, once we start anything like a formal barter system, it
>comes under the IRS.  The way to avoid that is to keep it a volunteer

How do you think the IRS is going to trace those banks and customers
behind all the anon mixes?
-- 
	Miron Cuperman <miron@extropia.wimsey.com>   | NeXTmail/mime ok
		       <miron@cs.sfu.ca>	     | Public key avail
	AMIX: MCuperman				     |
immortalcybercomputinglaissezfaire		     |




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eli Brandt <ebrandt@jarthur.Claremont.EDU>
Date: Wed, 25 Nov 92 10:30:40 PST
To: cypherpunks@toad.com
Subject: PGP on local machine (was Re: MacPGP)
In-Reply-To: <199211251002.AA24840@well.sf.ca.us>
Message-ID: <9211251830.AA13482@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> From: George A. Gleason <gg@well.sf.ca.us>
> Seems to me we need it for encryption as well...  For instance, telecom
> software which allows you to back out into a screen editor where you write
> something and then encrypt it, and then get back to telecom and transmit the
> ciphertext directly.

The following would require customization on both ends, but seems doable:

You compose the message, using emacs or some other Turing-complete editor.
You hit the "PGPify" key [sequence].
emacs echoes a special START string
The local comm program recognizes it and goes into "capture" mode.
emacs blats the plaintext to stdout, where it is captured.
emacs echoes a STOP string.
The comm program sees this, stops capturing, shells to DOS, and runs PGP.
emacs kills the original text block.
(emacs command ends)
The comm program shoves the cyphertext into the upload stream.
(comm macro reverts to lurk mode)
You send the message.

All of this, I think, could be implemented with available programs.
Kermit won't hack it on the local end, so maybe I'll switch to
Telemate.  This protocol would require a clean line or EC modem; is
this a problem?

It might be a better move to write a [shell, Perl] script that's a
drop-in replacement for Unix pgp: it goes through the whole protocol
above, and looks to the outside world as if it had done the work
itself.  People have written emacs macros (I think) to make this
work with mail; it could also be used as a unix-pgp replacement in
other places.

It might be nice if the plaintext were not echoed to the screen while
being transferred, too.

   Eli   ebrandt@jarthur.claremont.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 25 Nov 92 11:08:14 PST
To: Extropians@gnu.ai.mit.edu
Subject: Re: Scenario for a Ban on Cash Transactions
In-Reply-To: <9211251553.AA15780@wookumz.gnu.ai.mit.edu>
Message-ID: <9211251903.AA05946@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



In his usual fashion, Duncan Frissell has cogently made some arguments
as to why my scenario for a cashless society won't happen. I hope he's
right, but I doubt it. Since many of his comments are relevant to the
parallel discussion going on in the "Cypherpunks" list, I'm cc:ing
that list.

Duncan Frissell writes (from Britain):

> Why we won't have a cashless society - 
> 
> 1) 60% of US personal transactions (by number not value) are still in cash.

But here in the States nearly everyone has either a credit card or an
ATM card. Most supermarkets now take plastic...ATM/credit card readers
are installed in the checkout lanes. The clerks tell me they actually
prefer the plastic, as so little work is needed. (Much faster than
checks, which most people not using plastic use). This installed base
of card readers already covers about 80% of all common transactions, I
would estimate.

> 2) Bribe income of the rulers would be affected.

A good point, also made by Keith Henson (in e-mail). Politicians want
cash for off-the-record transactions, their sexual liaisons, etc.
Maybe the corruption of politicians will be our salvation! (More
likely: exemptions...Congress exempts itself from many laws. Also, the
various onerous financial disclosure laws directly affect politicians,
and they made it into law.)

> 3) The illiterate, the retarded, and those with poor management skills depend
>    on a cash accounting system to run their lives.  They would not be able
>    to survive in a card-based economy.  20% of the US pop. have no checking
>    accounts and 40% have no plastic.

I notice plenty of semi-literate folks handing their plastic to the
cashier! Those without checking accounts tend to use "money orders,"
though, so mandating a conversion would be possible. Many of those
without checking or plastic accounts simply don't "qualify." (Trend:
qualification standards have been dropping every year) A
government-run credit/debit card program would ensure that everyone
got a card. Illiteracy is no problem, as there is virtually nothing to
read or write when using plastic. (Adding voice synthesis to some of
the card readers would even be seen as a selling point with the blind
or physically disabled.)

> 4) The destruction of the Underground Economy would be socially regressive
>    since it would fall most heavily on the poor.  Poor households spend twice
>    their reported income.

Possibly true, but this won't cut the mustard when it comes to passing
the laws. The laws will be presented as a way to "close the loopholes"
on the rich, not to soak the poor.

The talk of a "welfare credit card" to deal with the theft of welfare
and social security checks (a big problem in the U.S., obviously
affecting mostly the poor) will likely result in some form of
government-mandated card system in the next couple of years. 

> 5) The destruction of the Underground Economy would hurt the Gross Domestic
>    Product and cause recession.

Probably not a concern to the planners, but perhaps. It is not
politically correct to talk about this.

> 6) Foreigners need to be able to participate in the system.  Unless *all*
>    nations jointly go to an electronic payments system, there will be loopholes
>    that domestic residents can exploit.

But foreigners already have to comply with U.S. banking laws (though
of course they often don't, but that's another story). Foreigners
planning to convert pounds or francs to cash dollars would simply
convert them to electronic dollars, "charging" up their
debit/credit/etc. card. (As a parallel, the law from 1933 to 1976 or
so was that Americans could not possess gold in any form except
jewelry or rare coins. Other countries had no such laws. Did we see
British visitors flouting the laws by spending gold guineas?)

> 7) As long as foreign practices differ, domestic residents could get overseas
>    Visa debit cards and ATM cards and avoid the domestic social controls.

This could be a real stopper. Perhaps the U.S. and its New World Order
will push for a nearly simultaneous conversion, as part of the GATT
talks, the various monetary talks, etc.

Also, using foreign-based cards could simply be declared illegal.
Tie-ins to Immigration and Passport control could allow foreign
visitors to use their foreing cards for, say, 90 days, or
whatever....this would also be a way to control illegal immigrants who
overstay their temporary visa. The cleanest solution would be to tie a
"tempory visa" to a "temporary VISA" (pun intended), in which a
visitor would receive a card upon arrival, just as he now changes his
francs and marks for dollars.

> 8) The vast majority of the world's population is still in a cash or barter 
>    economy and could not be converted to plastic.  This would leave overseas
>    cash that would be a system loophole.
See above.

> 9) There is now no central financial authority.  Electronic payments are 
>    transmitted to the payor banks by various networks and the banks themselves
>    authorize payment.  A central authority would be expensive and technically
>    challenging.

Ah, but these clearinghouses are becoming more tightly integrated. A
VISA transactions costs about $0.10, and this is dropping yearly. A
typical transaction can be sent out over phone lines in seconds and
over high-speed ISDN lines in fractions of a second. Fiber optic lines
make it ridiculously easy.

Besides, it it not necessarily the case that there would be one
central authority which would validate transactions (that would be too
vulnerable to single-point failures and sabotage). Transactions would
mostly be similar to today's transactions, with records sent
periodically to the government(s).


> 10)A central financial authority would exceed the institutional abilities of 
>    current international arrangements, would be opposed by the banks (cost and 
>    independence), would constrain the growth of the financial services industry
>    and would run counter to the trend of financial deregulation.

Here in the U.S. the banks have acquiesced to nearly all of the
onerous new reporting regulations (cash transactions over
$10,000--soon to be less--and disclosure laws) resulting from the War
on Drugs. Banks are now creatures of the government, jumping when told
to. Also, when the various laws are seen as _profit sources_ (as in
the FBI's Digital Telephony Bill, which would compensate phone
companies for tapping customers) then banks will be happy to add a
service charge to cover their expenses.

Furthermore, and this goes to your point below as well, banks will
push for legislation that forces theri competitors to do exactly the
same as they are doing. There are virtually no new banks appearing in
the U.S....they want a nice, safe, profitable world, not competition.
Forcing all transactions to go through them would fit their fondest
desires.

> 11)The Iron Law of Regulation.  Regulations create profits for their avoidance
>    and eventually break down as people take advantage of those profit 
>    opportunities.  Financial deregulation throughout the world in '80s was 
>    *not* caused by a decision of governments to give up power.  Deregulation
>    was an acknowledgment that old controls were dead.

Banks are suffering as new alternatives have appeared. Hence the talk
fo repealing the Glass-Steagall Act. Banks may see a cashless system
as their way to get back into the center of things.

> 12)Networks were originally thought to be centralizing.  In practice they have 
>    proven to be decentralizing.  How many machines/people access Internet?  Who
>    has central control over Internet?

The Internet may be physically decentralized, but logically it is very
centralized, in the sense that all messages to newgroups appear in one
very large feed, albeit sent out in pieces. That is, everybody in the
world is basically seeing the same "sci.crypt" group.

More to the point, the credit card clearinghouses are amazing
centralized (logically, if not physically...and a friend of mine who
consults for VISA headquarters--located in the Bay Area--says nearly
all VISA transactions flow into their facilities). I can access my
credit card balances nearly anyplace in the world. How's that for
centralization? 

> 13)An encrypted, anonymous, zero-knowledge-proof-credentialed market could be 
>    conducted without reference to an external government-controlled payment
>    system.

Here we agree, completely. This is my hope. If we can deploy our ideas
quickly enough, the scenario I describe may be headed off.

> These are just a few of the problems to be overcome.  A change that massive 
> would upset so many apple carts in the US and abroad that I don't think it is
> much of a risk.
> 
> Duncan Frissell

Thank you, Duncan, for your incisive comments, even though I disputed
most of them. This is an important debate, a lot more important, I
think, than debates on the rights of Martians and owls. (No offense to
Extropians intended!)

Our future is at stake.

--Tim May

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Wed, 25 Nov 92 09:17:58 PST
Subject: Remailers...
Message-ID: <921125165126_74076.1041_DHJ12-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


I think the remailing idea expressed via Tim (from David?) had
some nice features.  It would be very easy to do replies to someone
whom you didn't know but from whom you'd received some anonymous mail.
As I understand it, if I send mail anonymously to David, he won't
(of course) know who sent it.  If he replies, the mail will bounce
back to the forwarder.  And the forwarder has remembered my forwarding
request so that it can send the reply back to me.  After that it
deletes the remembered forwarding request for security.

I wouldn't object to this that much on security grounds; as David
pointed out, even a full implementation of Chaum's "mix" remailer
would fall to infiltration.  Instead, I think there are some issues
involving usability.

For one thing, it sounds like this system is use-once as far as the
anonymous return address.  If David replied to me, then thought of
something he wanted to add, his second message wouldn't get through to
me.

Another problem is, what if two people send anonymous mail to David
via the same forwarder.  Then, when he replies, how does the forwarder
know which of the two to forward the reply to?

It's also asymmetric, in that it will only work if one of the two
communicants knows the true address of the other.  A lot of the
interesting features of Tim's "crypto anarchy" only arise if
people can communicate without either one knowing the other's true
address.

Let me mention a couple of other ideas which I've heard of for anonymous
return addresses.  One idea was posted several months ago on the
Extropians list by Eric Messick.  (Is he on this list?)  It used
a "pseudonym-based post office box".  You would send a message to
a remailing server saying, "Please save mail addressed to pseudonym
XYZ123.  I will pick it up later.  Here is the public key I will
use to authorize the pick-up, and here is some digital cash to
pay for your trouble.  Thank you."  Then you send mail anonymously
giving XYZ123@remailer.com as your return address.  This mail
stacks up at the remailer which saves it for you.  At some later
date you send a signed message to the remailer saying, "OK, send XYZ123's
mail to me@me.com."

Eric Hughes had an idea which was somewhat like this but without
the delay aspect.  You would just set up an account with a remailer
whereby all mail to XYZ123 would be forwarded to yourself.  Then
XYZ123@remailer.com would be your return address.  This could include
David's idea if you asked the server to delete your pseudonym after
using it once.

All of these anonymous return address proposals can be enhanced by
using a cascade or chain of remailers for your A.R.A.

Chaum's "mix" remailer would save up a batch of cryptographically
protected messages, decrypt them, rearrange their order randomly, then
send them out.  This way if the remailer itself is secure but the
network connections to it are being monitored, the correspondance
between incoming and outgoing messages is lost.  The other ARA
suggestions could also benefit from this enhancement.

Chaum's idea for an anonymous return address was a somewhat more
complicated form of the ARA I've implemented for my remailer.  My
ARA is simply a forwarding instruction, encrypted with the public
key of the remailer.  The advantage of this system is that you don't
have to "register" with the remailer(s) in advance.  It's less
convenient than the other proposals, though, and there is the danger
that the public key(s) of the remailer(s) involved would be revealed
at some time in the future, which would then reveal that that old ARA
really was you.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Wed, 25 Nov 92 13:04:57 PST
To: cypherpunks@toad.com
Subject: Electronic Banking
Message-ID: <9211251953.AA01487@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Some time back Tim May suggested that we should do some experiments
with electronic cash.  He offered to do some Xeroxing if people would
"pay" him.

There are lots of proposals for electronic cash in the literature,
mostly very complex.  I think one of Chaum's simpler proposals would be
adequate for email "banking".  This proposal, from the beginning of
his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like
this:

1. Alice chooses a random x and r, and supplies the bank with
B=r^3*f(x) mod n, where f is a one-way function (like MD5), and n is
the modulus for the bank's public key.

2. The bank takes the third root of B (e.g. via an RSA decryption) and
sends it back to Alice: D = r * f(x)^(1/3), and withdraws one dollar from
her account.

3. Alice extracts C = f(x)^(1/3) by dividing D by r.  (Note that
division can be done mod n without knowing the factors of n, but it's
rather complicated.)

4. To pay Bob one dollar, Alice gives him (x, C).

5. Bob can verify that C = f(x)^(1/3), but he still has to send (x, C)
to the bank in order to make sure that x hasn't been used before.
Otherwise Alice could spend (x, C) twice.  The bank increases Bob's
account by one dollar.

This scheme is pretty simple and provides untraceability - the bank
saw B and D but not C, so although it can verify that (x, C) is legit,
it can't correlate that with Alice's withdrawal.

The main disadvantage of this approach is that Bob has to send (x, C)
to the bank right away (or at least before sending Alice anything in
return for her cash) to verify that the cash hasn't been used before.
But in email, where turnarounds of a day or more aren't unusual, this
should be tolerable.

Alice and Bob could be pseudonyms, using anonymous addresses to
communicate with each other and with the bank.

Different denominations of cash could correspond to different
exponents than "3" in the example above.  (That is, $1 would use
C=f(x)^(1/3), $2 would use C=f(x)^(1/5), $4 would use C=f(x)^(1/7),
and so on.)

Technically, this would be quite easy to implement, using the code in
PGP for the arithmetic, and MD5 for the one-way function.  We'd need
to define a few message formats.  The RFC1113 ascii encoding from PGP
could be used as well.

The "social" problems are more challenging, it seems to me.  What is
the backing for this electronic money?  Why do people care what their
bank balances are?  Is this stuff really worth anything?

One possibility is to base digital cash on real money.  People would
open a pseudonymous account via email, then postal-mail dollars to the
bank, enclosing their account number so the bank would know whom to
credit with the deposit.  Later, if someone wanted to withdraw "real
money" from their account they would have to give a real postal
address where it could be mailed.  Now the electronic money is worth
real dollars.  Even if people didn't deposit or withdraw very often,
it still has value because of the backing.

Unfortunately, this approach would currently be illegal (at least,
unless you actually were a real bank!).  If there were some way the
bank itself could be anonymous, it might survive, but I don't see how
to mail it money while keeping the anonymity.  Still, we could
consider experimenting with this on a small scale with accounts of no
more than a few dollars.  As long as it was clearly an experiment I
doubt that any prosecutions would result even if it attracted
government attention, because the expense involved in court costs
would be so disproportionate to the few dollars involved in this
technically illegal act.

Another approach would be not to try backing the digital cash at all,
or rather backing it implicitly by the determination of various people
to accept it and perform services or supply goods in return for it.
Tim's offer to Xerox papers in return for digital cash would be one
example.  Perhaps others could provide some other services.  It would
be great if some shareware author would accept digital cash as a
symbol of support for crypto anonymity.

One problem that I see with this approach is how you determine the
size of the money supply.  Or, in other words, how does new digital
cash get started circulating?  How do people get new accounts, and how
much money is in them?

If these problems can be solved, a big advantage of this approach is
that the banker can be anonymous.  He would be known only by his
anonymous address and his public key(s).  This would provide some
safety in the event that even a small-scale experiment like this
was targetted for a crackdown.

Another issue is the prospect of multiple "banks", each issuing their
own (incompatible) cash.  How would they compete?  Perhaps in terms of
rapid turnaround?  Some might choose to be anonymous, others would go
public.  The latter would have the advantage that people might trust
them more, but OTOH there is more chance of your bank account
disappearing after a crackdown for a public bank than an anonymous
one.

Lots to think about here!

Hal
74076.1041@compuserve.com






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Wed, 25 Nov 92 12:30:56 PST
To: cypherpunks@toad.com
Subject: Re: An easy-to-reply anonymous mail scheme
In-Reply-To: <9211251835.AA23411@novavax.nova.edu>
Message-ID: <9211252030.AA24576@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



>
>So to use this, you would generate a public/private key pair, and compute the
>hash function of the public part.  Anonymously post the public key to
>alt.key.announce, and then send your message by whatever means you like (anon
>mail, anon post to a regular newsgroup, anything) using reply.HASH@remailer.com
>as your return address.  Then watch alt.w.a.s.t.e for replies and decrypt
>as received... 

one problem is that pgp labels public/private key pairs with strings
(thus I have to create a public/private key pair with a unique label string
that has nothing to do with my name) the problem still exists that
every message  posted to alt.w.a.s.t.e  with have my pgp key label string.

pgp does not support unlabeled crypted test (eg: I can had it random
cyphertext and have it figure out public/private key pair to use (by
trying every key in my rings)(




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Wed, 25 Nov 92 09:17:33 PST
To: cypherpunks@toad.com
Subject: Re:  Random Numbers Boxes and Cypher Processers
Message-ID: <9211251629.AB05506@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


>Why do encryption in the modem instead of the host cpu?

A point that hasn't been made painfully clear yet: "DSP--Digital
Signal Processor" chips are really just fast processors for repetitious 
arithmetic--just what RSA needs.  Maybe some experience in
programming them for that sort of purpose would be useful.

-fnerd
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: rfm@Eng.Sun.COM (Richard McAllister)
Date: Wed, 25 Nov 92 13:09:10 PST
To: libernet@dartmouth.edu
Subject: Re: SF Bay Area Parties
Message-ID: <9211252108.AA05130@urth.Eng.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain


Edgar Swank wrote:
> Cypherpunks,          <cypherpunks@toad.com>
>  Extropians           <extropians@gnu.ai.mit.edu>
   Libernet             <libernet@dartmouth.edu>
 
> Since all the above groups, of which I am a member, are not known
> for sponsoring social functions, I suggest we co-opt the Pen SFA
> parties.  Their latest "Winnie" newsletter is attached. Please note
> and follow "rules".  I especially recommend the 12/26 party. ...

Interested people are definitely invited to attend PenSFA parties
(though not to "co-opt" them..), but we prefer not to post the meeting
notices to random mailing lists since they include hosts' addresses and
phones.  [Edgar didn't know this because I failed to tell him; my
fault, not his.]  But please don't forward the whole Winnie on to other
lists. (Especially, don't post it to USENET...)

If you'd like more information on PenSFA, email me, I have a information
handout to give you; also email me to get on the list for more announcements.

Rich (rfm@eng.sun.com)



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 25 Nov 92 10:36:01 PST
To: anon.list@pax.tpa.com.AU
Subject: An easy-to-reply anonymous mail scheme
In-Reply-To: <199211251815.AA16797@buila.NSD.3Com.COM>
Message-ID: <9211251835.AA23411@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> >is this: Just include a public key in your post.  And ask any repliers to 
> >post to the newsgroup, encrypted with that key.  No-one else but you can 
> >decrypt the reply, and no-one can know that you did, since everyone receives
> 
> all of my own and everybody elses schemes is that it requires an INVOLVED
> replier.  I need some way that I can send out an anonymous email, and have
> the receiver of that email just hit "r" to reply to me.  If they have

Ok, if that is what you want, then the following procedure will let you
do exactly that: post anonymously, with a reply address that people can
just 'r' to. And no-one (not even the host that is handling the replies)
has to know who you are.  

There exists a site, lets call it remailer.com.  It watches the newsgroup
alt.key.announce for messages with the "Subject: remailer public key notice"
that contain a public key.  It takes each public key, and perofmrs some
sort of hash function on it, tcreate a short "key id". (note: the hash
function must be cryptographically strong, i.e. it should be very difficult
to construct another key with the same hash value). It stores hash and the
key in a database.  Then whenever it receives a mail message
to reply.HASH (where HASH is the key id), it encrypts the message with the 
associated public key, destroys the plaintext message, and posts the ciphertext
to alt.w.a.s.t.e.

So to use this, you would generate a public/private key pair, and compute the
hash function of the public part.  Anonymously post the public key to
alt.key.announce, and then send your message by whatever means you like (anon
mail, anon post to a regular newsgroup, anything) using reply.HASH@remailer.com
as your return address.  Then watch alt.w.a.s.t.e for replies and decrypt
as received... 

All the recipient(s) have to do is press 'r' key and type the answer.

You are guaranteed anonymity because no-one can find out who decrypted
the alt.w.a.s.t.e message, since everyone received it.

All you need is a good way to anonymously post to a newsgroup.

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 25 Nov 92 10:41:46 PST
To: anon.list@pax.tpa.com.AU
Subject: Re: anonymous reply
In-Reply-To: <199211251829.AA27022@johanna4.hsr.no>
Message-ID: <9211251841.AA23551@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> > replier.  I need some way that I can send out an anonymous email, and have
> > the receiver of that email just hit "r" to reply to me.  If they have

> Here is an example of how to use the cryptographic remailer at
> <hal@alumni.caltech.edu> to implement an anonymous return address.

> But the again do you trust hal@alumni.caltech.edu...

With conventional remailer schemes such as this one, you are announcing
your True Name (or at least your True Internet Mailbox) to someone you
must trust. With my scheme (posted earlier today) you don't need to trust
anybody except yourself (to not make a dumb mistake like including a signature).


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 25 Nov 92 14:23:18 PST
To: cypherpunks@toad.com
Subject: Re: Electronic Banking
In-Reply-To: <9211251953.AA01487@nano.noname>
Message-ID: <9211252219.AA00550@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Hal Finney makes some very good points about anonymous banking and
some experiments we may try in the near future.

(First let me dispose of a minor item.)

> Some time back Tim May suggested that we should do some experiments
> with electronic cash.  He offered to do some Xeroxing if people would
> "pay" him.

(A minor note: I ended up doing the Xeroxing for free, which hasn't
yet been declared illegal...though I presume you'll all carefully note
this on your tax returns, as such "barter exchanges" are reportable
income. In theory, which shows how hopeless tax collection is
becoming, all of our "mutual consulting" on this list, and on the Net
in general, is _taxable income_--just as if we were plumbers and carpenters
getting together to work on each other's houses. A crazy system.)

Back to the important stuff. Hal continues:

> There are lots of proposals for electronic cash in the literature,
> mostly very complex.  I think one of Chaum's simpler proposals would be
> adequate for email "banking".  This proposal, from the beginning of
> his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like
> this:

(Hal's excellent summary of Chaum's system elided)

> Technically, this would be quite easy to implement, using the code in
> PGP for the arithmetic, and MD5 for the one-way function.  We'd need
> to define a few message formats.  The RFC1113 ascii encoding from PGP
> could be used as well.

This sounds great! (But I worry that the handful of you already doing
the programming of PGP, new versions, MacPGP, remailers, etc., will
get overloaded and/or burned out. I'd offer to help, but my
programming these days is limited to fiddling with Mathematica and a
little bit of Smalltalk and Scheme/LISP.)

> The "social" problems are more challenging, it seems to me.  What is
> the backing for this electronic money?  Why do people care what their
> bank balances are?  Is this stuff really worth anything?

And the lesson we learned from PGP 2.0 is that actually getting
_something_ out there for people to play around with is crucial.
Getting "PGDC" ("Pretty Good Digital Cash") in use will be a harder
sell than PGP deployment was, because most people don't understand the
ideas, see no real pressing need, and can't do much in any case
without an "economy" of users.

I've long thought that a "Black Market AMIX" would be one such use,
but I won't get into that here.

> One possibility is to base digital cash on real money.  People would
> open a pseudonymous account via email, then postal-mail dollars to the
> bank, enclosing their account number so the bank would know whom to
> credit with the deposit.  Later, if someone wanted to withdraw "real
> money" from their account they would have to give a real postal
> address where it could be mailed.  Now the electronic money is worth
> real dollars.  Even if people didn't deposit or withdraw very often,
> it still has value because of the backing.
> 
> Unfortunately, this approach would currently be illegal (at least,
> unless you actually were a real bank!).  If there were some way the
> bank itself could be anonymous, it might survive, but I don't see how
> to mail it money while keeping the anonymity.  Still, we could
> consider experimenting with this on a small scale with accounts of no
> more than a few dollars.  As long as it was clearly an experiment I
> doubt that any prosecutions would result even if it attracted
> government attention, because the expense involved in court costs
> would be so disproportionate to the few dollars involved in this
> technically illegal act.

Warning! Recently, a bunch of bowlers (women, no less) were busted for
illegal gambling because of their "pot" they were bowling for. After
much public outcry and laughter at the authorities, the charges were
either dropped or reduced. I mention this because casual bowlers evoke
sympathy, hackers and cypherpunks do not.

> One problem that I see with this approach is how you determine the
> size of the money supply.  Or, in other words, how does new digital
> cash get started circulating?  How do people get new accounts, and how
> much money is in them?

We're in new territory here. The start of a new kind of economy. Lots
of experimentation and trial and error work will be needed.

> If these problems can be solved, a big advantage of this approach is
> that the banker can be anonymous.  He would be known only by his
> anonymous address and his public key(s).  This would provide some
> safety in the event that even a small-scale experiment like this
> was targetted for a crackdown.

Yes. And also anonymous "escrow services" which are like banks but
which serve other functions, such as holding the money in a
transaction so that Alice cannot take the money from Bob and refuse to
deliver on her side of the deal.

All of these entities must be "pseudonymous" (a clumsy word), in that
digital pseudonyms are supported (a la the work of Hughes, Finney, and
Janek Martinson) and True Names cannot be traced.

> Another issue is the prospect of multiple "banks", each issuing their
> own (incompatible) cash.  How would they compete?  Perhaps in terms of
> rapid turnaround?  Some might choose to be anonymous, others would go
> public.  The latter would have the advantage that people might trust
> them more, but OTOH there is more chance of your bank account
> disappearing after a crackdown for a public bank than an anonymous
> one.

Banks, escrow services, etc. will all have "reputations" and credit
ratings (from crypto versions of Standard and Poors, themselves
operating only as a pseudonym!). All of this will evolve over time.

> Lots to think about here!
> 
> Hal

That's for sure. Incredibly good points being made by everyone!

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Wed, 25 Nov 92 15:38:09 PST
To: yanek@novavax.nova.edu
Subject: Re:  RS232 Crypto Dongle (idea for widely accessible crypto technology)
Message-ID: <9211252337.AA01494@servo>
MIME-Version: 1.0
Content-Type: text/plain


I've also been thinking about the risks of running crypto software on
hackable PCs and ways of protecting against this with external special
purpose devices.

My thinking is to limit the external "dongle" to the one function that
is truly sensitive and worthy of special protection: RSA secret key
operations.

It seems to me that whenever you use a PC to encrypt or decrypt
something, you have to accept the risk that it might have been hacked,
and whatever you do on it might be secretly recorded.

But when I now run PGP (or any similar package) on a machine, I must
risk much more than this every single time I type in my pass phrase,
namely *everything* that ever was or will ever be encrypted with this
same RSA key pair. This may well be an unacceptable risk, especially
if I'm temporarily borrowing somebody else's machine or using one in a
public area. I see this as THE major obstacle to our goal of routinely
encrypting all communications, sensitive or otherwise, as a way of
"desensitizing" the world to the use of cryptography.

The way around this risk is to move the RSA secret key storage and
processing operations to some external dongle. The device would have
only one primary function -- the execution of an RSA secret key
operation. It would not allow the secret key to be read out of the
device, although it might have a "zeroize" function to destroy it. (It
might also include a good random number generator for the convenience
of the host computer.)

Everything else (data compression and armoring, public key operations,
symmetric cryptography, etc) can and should go in the PC where cycles
and memory space are much more plentiful.

If the dongle has a built-in keypad, then it could store your RSA
secret key encrypted with a PIN that you'd have to enter to enable the
device. This would protect you if the device were stolen. Of course,
the best protection is to make the device so small that you can
conveniently keep it with you at all times instead of having to store
it someplace.

I believe that "smart cards" are already available on the market that
do these or similar functions, although they are much more widespread
in Europe than in the US.

Comments?

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 25 Nov 92 12:44:36 PST
To: shipley@tfs.COM (Peter Shipley)
Subject: Re: An easy-to-reply anonymous mail scheme
In-Reply-To: <9211252030.AA24576@edev0.TFS>
Message-ID: <9211252044.AA28256@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> >as your return address.  Then watch alt.w.a.s.t.e for replies and decrypt
> 
> one problem is that pgp labels public/private key pairs with strings
> (thus I have to create a public/private key pair with a unique label string
> that has nothing to do with my name) the problem still exists that
> every message  posted to alt.w.a.s.t.e  with have my pgp key label string.

This is not a problem at all.

For every anonymous "identity" you want to maintain, you would have a key
pair (public/private).  The "label" part could contain anything you want,
or nothing at all (a space, or a dash, or the word "anonymous") but it would
be more convenient if you assigned a pseudonym.

> pgp does not support unlabeled crypted test

Just because (current version of) pgp does not support something does not
mean it can not be done.

> (eg: I can had it random cyphertext and have it figure out public/private
> key pair to use (by trying every key in my rings)

This would be a waste of time, and possibly imprctical if you have any
significant number of keys. 

You should not have to try each key, because the post would contain in the
Subject field the hash value of the public key, and using that you could
instantly identify which private key to use.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 25 Nov 92 15:49:42 PST
To: cypherpunks@toad.com
Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology)
In-Reply-To: <9211250712.AA03659@novavax.nova.edu>
Message-ID: <9211252349.AA13510@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Yanek writes:
>Also, it would not require ANY special software on the host or the
>pc, nor any special terminal.  [A magical kingdom of compatibility is
>described.]

In practice, it will be impossible to make a device that does anything
transparently.  Software has to be rewritten and redesigned around
crypto security.  It is wise not to underestimate or overestimate the
difficulty of doing this.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Wed, 25 Nov 92 16:07:41 PST
To: cypherpunks@toad.com
Subject: Re: An easy-to-reply anonymous mail scheme
Message-ID: <9211252352.AA01919@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


The problem with the idea of posting anonymous mail to a newsgroup is
sheer volume.  Remember, we aim at a system where a large fraction of
mail is potentially being done this way.  Imagine if almost all email
was done today by posting to newsgroups!  There is probably thousands
of times as much email traffic as news traffic now.  It would totally
swamp the system.  You'd literally have to send every email message
sent by any user in the world to _every_ user in the world, in effect.

As Yanek says:

> You are guaranteed anonymity because no-one can find out who decrypted
> the alt.w.a.s.t.e message, since everyone received it.

This really won't scale to large numbers of users.  Yanek also writes:

> > Here is an example of how to use the cryptographic remailer at
> > <hal@alumni.caltech.edu> to implement an anonymous return address.
> 
> > But the again do you trust hal@alumni.caltech.edu...
> 
> With conventional remailer schemes such as this one, you are announcing
> your True Name (or at least your True Internet Mailbox) to someone you
> must trust. With my scheme (posted earlier today) you don't need to trust
> anybody except yourself (to not make a dumb mistake like including a
> signature).

This is why you would want to use a chain of remailers as your return
address, what Chaum calls a "cascade".  No single remailer sees the
correspondance between your anonymous address and your real address.
Only by breaking all of them can the bad guys find out who you are.
Ideally, remailers would operate in a variety of countries with
different laws, making it difficult to crack them all.

Remailers could be designed to periodically flush themselves, deleting
old keys and/or pseudonym maps.  This way anonymous addresses would
have a limited lifetime if desired, and the attackers would have only
a finite time window to break all the remailers involved.  (Different
keys/pseudonyms could have different lifetimes as needed.)

We could also imagine that there are lots of remailers - not just
dozens, or hundreds, but millions of them.  Maybe almost everyone runs
a "cheap" remailer on the side, collecting a few cents in digital cash
for each message they pass, enough to pay for their own messages.

Putting all this together, you could have an anonymous address which
passes through, say, 10 remailers which might be any of the millions
of remailers in the world.  It could have a limited lifetime of only a
few hours for some ultra-sensitive applications, with the remailers
involved flushing their databases after that time.  To break this, the
enemy would have to sequentially break into machines all over the
world, one after another, defeat any physical barriers (locks, men
with guns), overcome tamper-resistance in the computers, break the
encrypted files, and find out what the next step is in the address
cascade, all in a couple of hours.  This doesn't seem possible.

Hal
74076.1041@compuserve.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Wed, 25 Nov 92 15:55:15 PST
To: submit@eff.org
Subject: The age of the engineers...
Message-ID: <9211252354.AA12510@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


------- Forwarded Message

To: junk
Subject: quotd
Date: Wed, 25 Nov 92 14:12:06 -0800
From: ambar@cygnus.com

- ------- Forwarded Message

Date: Wed, 25 Nov 92 17:06:28 EST
From: CyberBunny <kjc@cs.rutgers.edu>

This is not the age of pamphleteers. It is the age of the engineers. The
spark-gap is mightier than the pen. Democracy will not be salvaged by men
who talk fluently, debate forcefully and quote aptly.

                Lancelot Hogben
                Science for the Citizen (1938)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 25 Nov 92 15:58:26 PST
To: miron@extropia.wimsey.com
Subject: How far is to far?
In-Reply-To: <1992Nov25.101452.11440@extropia.wimsey.bc.ca>
Message-ID: <9211252357.AA13991@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Miron writes:
>How do you think the IRS is going to trace those banks and customers
>behind all the anon mixes?

Easy.  This one, though, is not in the crypto literature to my knowledge.

Attack by regulation.

Not, mind you, that it will be enforceable without a bn on
cryptography in general.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Wed, 25 Nov 92 15:58:50 PST
To: gnu@cygnus.com
Subject: Re: Electronic Banking
In-Reply-To: <9211252219.AA00550@netcom.netcom.com>
Message-ID: <9211252358.AA12549@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


> > Unfortunately, this approach would currently be illegal (at least,
> > unless you actually were a real bank!).

Please point out the law(s) that make it illegal.  Speculation is fine,
but let's do some informed speculation.

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Wed, 25 Nov 92 16:25:25 PST
To: cypherpunks@toad.com
Subject: Unlabelled PGP messages
Message-ID: <9211260016.AA01923@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Peter Shipley points out that PGP messages are labelled with an
identifier of the person they are sent to.  This hurts the anonymity
of the messages somewhat.

What PGP actually puts in the cleartext message header is the "Key ID"
of the recipient.  This is the low-order 64 bits of the RSA modulus
"n" of his key.  (PGP displays only the low-order 24 bits when it
shows key ID's, but it keeps 64 bits internally.)

I understand that there was some discussion during the development of
PGP 2.0 of having a mode where this wouldn't be done.  One possibility
would be to output a key ID of all zeros for a message which wanted to
hide who it was for.  Then, as Peter suggests, it would either be
trial-decrypted by all of the secret keys you have, or, more simply,
it would just try your "default" secret key.  Most people only have
one secret key so both methods would be the same in most cases.  Doing
it the second way would be a pretty easy patch to PGP.

I'm not so sure now that this feature is that helpful.  First, you
don't have to put your real name in the "user name" field.  You could
use a pseudonym.  So you really don't have to give much information
away about yourself the way it is now.

Also, if someone is sending a message to you using encrypting
remailers, they would encrypt it using your key, add remailing
instructions for the last remailer in the chain, encrypt that using
that remailer's keys, add remailing instructions for the next-to-last
remailer, encrypt it again, and so on.  (This would be done
automatically by some future software - you wouldn't want to do this
by hand!)  The result is that the mail you send does not expose the
key ID of your recipient.  That information is only revealed when it
comes out of the last remailer in the chain.  And by that time, it's
no secret, since that last remailer is using the true email address of
the recipient anyway.  So it's not giving anything away.

For the other kind of anonymous messaging, where you just post to a
newsgroup or use some other kind of "broadcast" system, the key ID is
revealed and for this case it might be better to hide it.  But, the
key ID can be useful in this application by letting you know which
messages you should decrypt.  No one has to know that a particular key
ID is "you".  You can still download 1000 messages and only read yours
without anyone knowing which ones you read.  But with key ID hidden
you would have to decrypt them all to see which are yours.  Do you
want to decrypt all 1000?  This will take minutes, hours, or days,
depending on your key size and computer speed.  (Most of the decrypt
time is spent doing the RSA step, at least for most messages, and you
can't tell if it's for you without doing that step.)

This still might be a good idea, but I'm not sure...

Hal Finney
74076.1041@compuserve.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "DrZaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Wed, 25 Nov 92 17:59:06 PST
To: cypherpunks@toad.com
Subject: RE: PGP on local machine (was Re: MacPGP)
Message-ID: <58809.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


In Message Wed, 25 Nov 92 10:30:09 PST,
  Eli Brandt <jarthur.Claremont.EDU!ebrandt@netcomsv.netcom.com> writes:

>You compose the message, using emacs or some other Turing-complete editor.
>You hit the "PGPify" key [sequence].
>emacs echoes a special START string
>The local comm program recognizes it and goes into "capture" mode.
>emacs blats the plaintext to stdout, where it is captured.
>emacs echoes a STOP string.
>The comm program sees this, stops capturing, shells to DOS, and runs PGP.
>emacs kills the original text block.
>(emacs command ends)
>The comm program shoves the cyphertext into the uploadt editor to write your messages then
you've just lost the whole reason for encryption.
TTFN!
DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 25 Nov 92 16:30:25 PST
To: cypherpunks@toad.com
Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology)
In-Reply-To: <9211252337.AA01494@servo>
Message-ID: <9211260030.AA17523@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Phil K. writes:
>My thinking is to limit the external "dongle" to the one function that
>is truly sensitive and worthy of special protection: RSA secret key
>operations.

Phil's comment are right on.  There is a need for you secret keys
to be easily and physically relocatable.

Re: key compromise
>I see this as THE major obstacle to our goal of routinely
>encrypting all communications, sensitive or otherwise, as a way of
>"desensitizing" the world to the use of cryptography.

It is my own opinion that there will be a market for personal
protection devices only when data is worth money.  Data will be worth
money when some data _is_ money.

>only one primary function -- the execution of an RSA secret key
>operation. [...]
>it might have a "zeroize" function to destroy it.

I refer to this as WEEM: Write, Erase, Encrypt Memory

>Everything else (data compression and armoring, public key operations,
>symmetric cryptography, etc) can and should go in the PC where cycles
>and memory space are much more plentiful.

Depending on the silicon size and production volume, you could
probably use this device for all modular exponentiation operations.
Or a cheap version could use a DSP module from a cell library and do
all the arithmetic more slowly.

>If the dongle has a built-in keypad, then it could store your RSA
>secret key encrypted with a PIN that you'd have to enter to enable the
>device. 

Not only a keypad, but a full 4-function calculator with an LCD
display as well! :-)

>I believe that "smart cards" are already available on the market that
>do these or similar functions, although they are much more widespread
>in Europe than in the US.

Smart cards have the disadvantage that their die size is pretty
severely limited.  They have to fit within the thickness of a credit
card and withstand repeated flexure.

Much better for this application is the PCMCIA standard, which has
plenty of room for circuitry.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Wed, 25 Nov 92 16:36:39 PST
To: cypherpunks@toad.com
Subject: The Cypherpunks Mail Project
In-Reply-To: <775@morgan.demon.co.uk>
Message-ID: <9211260036.AA18162@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Tony writes:
>I access the net 
>through a dial up from a MS-Dos machine running KA9Q software. My 
>PGP is of the stand alone sort. 

I myself read my own mail on an MSDOS machine acting as a terminal
over a dialin.  The unix host is not overly secure, and I'm not about
to go putting keys on it.  I've been thinking about how to solve my
own encryption problem, you can be sure.

But most of the people on the list are reading mail on Unix machines,
and a simple piping interface is the first thing to implement.  I myself
may not use it at first, but it is a start.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Wed, 25 Nov 92 16:47:49 PST
To: hughes@soda.berkeley.edu
Subject: Re:  RS232 Crypto Dongle (idea for widely accessible crypto technology)
Message-ID: <9211260047.AA01958@servo>
MIME-Version: 1.0
Content-Type: text/plain


>Much better for this application is the PCMCIA standard, which has
>plenty of room for circuitry.

I had this in mind too. But there's a problem -- if we have to depend
on commercial manufacturers to build these things, how will we know if
we can really trust them? I'm not impugning the manufacturers
themselves, as it's entirely possible that the FBI and/or NSA wouldn't
even let them build and sell a device like this if it's "too" secure.

That's the paradox of freely-available crypto software like PGP.  The
software, including source, is open for inspection by all. But because
it runs on general purpose computer hardware, it's vulnerable to all
of the usual computer security attacks (viruses, modifications to
secretly record or transmit keys, keystroke monitors, etc). Going to
small, dedicated pieces of hardware removes these vulnerabilities, but
then we're right back where we started -- with an opaque piece of
commercial hardware whose secure operation we can't verify.

Unless, of course, we can get the technology to build PCMCIA cards
ourselves out of readily available parts...

Phil







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: bwebster@pages.com (Bruce F. Webster)
Date: Wed, 25 Nov 92 17:47:35 PST
To: cypherpunks@toad.com
Subject: News item
Message-ID: <9211260049.AA05336@pages.com>
MIME-Version: 1.0
Content-Type: text/plain



Is this sudden flood of cypherpunk mail this afternoon mean we're all  
avoiding doing any work before taking off for Thanksgiving? ;-)

AP news item in today's San Diego Union:

Headline: "CIA chief hints change needed in ban on probing Americans"

Excerpts:
 	WASHINGTON--CIA Director Robert Gates says changes might be  
needed in the U.S. law that forbids the agency from collecting  
information about Americans or U.S. companies.
	Such changes might enable the CIA to better support the  
Justice Department and other law enforcement agencies, he said in an  
interview with the Associated Press.
	The idea grew out of a recent storm of accusations by  
Democrats in Congress, Justice Department officials and a federal  
judge that the CIA withheld information in the case of $5.5 billion  
lending scheme to Iraq by an Atlanta bank.
	...
	[Gates said] the case of the Iraqi loans raises a broader  
issue of what the CIA is expected to do to aid law enforcement in  
such fields as financial crimes.
	Under current law, the CIA is strictly forbidden to collect  
information on Americans or American companies.
	"At some point it seems to me, very early on, we and  
Justice...and the Congress are going to have to...have some sort of  
serious discussion about whether there are changes in the law that  
are needed that will clarify some of the ambiguities and what we can  
and cannot do in support to law enforcement," Gates said.
	He did not elaborate.
	...
----------------




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 25 Nov 92 17:23:22 PST
To: cypherpunks@toad.com
Subject: Crypto Dongles and Tamper-Resistant Modules
In-Reply-To: <9211260047.AA01958@servo>
Message-ID: <9211260119.AA02600@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Some points about the security of "crypto dongles" and other personal
security devices.

Phil Karn writes:

> >Much better for this application is the PCMCIA standard, which has
> >plenty of room for circuitry.
> 
> I had this in mind too. But there's a problem -- if we have to depend
> on commercial manufacturers to build these things, how will we know if
> we can really trust them? I'm not impugning the manufacturers
> themselves, as it's entirely possible that the FBI and/or NSA wouldn't
> even let them build and sell a device like this if it's "too" secure.

The crucial chips could be built under "open inspection" conditions,
much like having source code for inspection prior to compilation on
one's own--presumably trustworthy--machines. Several such vendors
could be used, with independent auditors observing the processing
steps throughout. (Merely the threat of a surprise inspection is
probably enough to head off obvious attempts to insert hardware
trapdoors and the like.) This seems like a solvable problem.

The issue of whether the NSA will let such devices be built is
interesting. There was the story of the "PhasorPhone," or somesuch,
from some years back, with the story that the inventor, in Seattle,
filed a patent application and got back a statement that the device
was now classified and could not be talked about (let alone marketed).
However, I've heard of no such cases recently.

Other countries have excellent wafer fab facilities and could of
course build the chips and the complete units. Whether Americans could
buy them....

Tamper-Responding Modules (TRMs)

Robert Brooks mentions using e-beam probers to read the bits out, and
various etches, etc. TRMs came up several weeks ago on this list, and
are mentioned in the Glossary posted a few days ago.

Even if the TRMs can eventually be gotten into, probably at high cost,
they will in most cases leave signs of having been opened, analyzed,
probed, etc. (that's the "responding" part of TRM). The nuclear
weapons people at Sandia and elsewhere (Russia, one now hopes) have
been dealing with the problem for several decades. Some of their work
has filtered out to the public literature.

Smartcards often have basic TRM methods applied to them.

If there's interest, I can summarize.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Wed, 25 Nov 92 18:04:11 PST
To: karn@qualcomm.com (Phil Karn)
Subject: Re: RS232 Crypto Dongle (idea for widely accessible crypto technology)
In-Reply-To: <9211260047.AA01958@servo>
Message-ID: <9211260203.AA15805@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


> I had this in mind too. But there's a problem -- if we have to depend
> on commercial manufacturers to build these things, how will we know if
> we can really trust them? ...
> Unless, of course, we can get the technology to build PCMCIA cards
> ourselves out of readily available parts...

There's an implied assumption in the above that "we" and "commercial
manufacturers" are not the same people, and that if "we" could build
the cards "ourselves", then "we" could trust them.  But any of "us"
builds PCMCIA cards and offers them to "us" for sale, they will have
to satisfy "us" that "we" truly understand its level of security.

Enough pronouns?  The point is that we can't trust ourselves any more
than faceless manufacturers.  It's more likely the manufacturers won't
make some bonehead mistake that renders the system easy to break.  And,
as dramatized in "Sneakers", even the best people can be pressured by
the government if they or their loved ones are vulnerable.

John Draper was proposing to manufacture rs232 random number
generators -- would you buy a used random number from this man?  If
you could see its design, you might.  If not, probably not.

There's a tradition that security software has to be made available
in source form because the customers insist on it.  Let's continue this
trend and make sure it applies to hardware, too.

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Wed, 25 Nov 92 18:07:42 PST
To: cypherpunks@toad.com
Subject: chip verification  ( Was: Tollhouse Cookies  :-)
Message-ID: <9211260206.AA08221@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



"The crucial chips could be built under "open inspection" conditions,
 much like having source code for inspection prior to compilation on
 one's own--presumably trustworthy--machines. Several such vendors
 could be used, with independent auditors observing the processing
 steps throughout. (Merely the threat of a surprise inspection is
 probably enough to head off obvious attempts to insert hardware
 trapdoors and the like.) This seems like a solvable problem."


It seems to me that an ostensibly digital device with a fixed number
of pins could be regarded as a finite state system, and systematically
analyzed accordingly, IE, traverse the set of possible combinations of
pins and signal levels and verify that it behaves in accord with pub-
-lically available specifications.

I'm no circuit designer ( yet ), but it seems to me that the microchip
might be subject to design to make it conform to such tests, yet still
contain additional circuitry which is undocumented. It might also have
analog circuitry, I suppose, although I cannot immediately conceive of
a use for such a thing. ( Of course, nanotech rears its ugly head, but
that sword cuts both ways and, until it manifests, is irrelevant. )

Perhaps a chip could be tested, at the cost of additional time, by a
systematic profiling of the finite boundaries of the device as repre-
-sented by the combination of pins being stimulated, the combination
of pin input voltage levels, and the resulting pin output voltages.
If you want to be fanatical, you can also profile the resulting fields.
It seems to me that it would be difficult to defy such a systematic
profiling. ( I guess one could also test the I:E:R ratios at each of
the states to further detect bogus circuitry, as well as borderline
products. )

Why quality assurance lines don't do this on a chip-by-chip level now is
beyond me. I'll bet the Japanese do now, or are working on it ...


-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

                    Klein flask for rent. Inquire within.
 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 25 Nov 92 15:31:10 PST
To: gg@well.sf.ca.us (George A. Gleason)
Subject: ease of use of encryption
In-Reply-To: <199211251002.AA24840@well.sf.ca.us>
Message-ID: <9211252330.AA04789@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> re Tai's item about more user-friendly decryption on the Mac version....
> 
> Seems to me we need it for encryption as well...  For instance, 
>  Having to go offline, go into WP, compose, go to crypto and encrypt,
> then go back to telecom, link up again, and transmit.... 

This is where my little Crypto-Dongle would help.  To encrypt, just
flip a switch and type.  

Same thing for decryption... flip a switch and everything received is
decrypted...


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dclunie@pax.tpa.com.AU (David Clunie)
Date: Wed, 25 Nov 92 00:03:49 PST
To: cypherpunks@toad.com
Subject: Re: CypherPunks Mailing list
Message-ID: <9211250803.AA01586@britt>
MIME-Version: 1.0
Content-Type: text/plain


> From yanek@novavax.nova.edu Wed Nov 25 18:20:16 1992
> There always remains the issue of trust.  How can I know that your system 
> has not been compromised, and is logging all in/out messages, and forwarding
> them to FBI.  This could be happening even without you knowing, for example
> if "they" tap your network connection.

Absolutely. This is a problem with any system that involves forwarding. For
instance the currently proposed scheme advocates encrypting the address
to be forwarded too, the remailer server still could have its mail
tapped and the same correlation made. Of course my system seems much weaker
in the sense that if the server is compromised the database is there for
all to see. Of course the other system is just as weak in that if its
server is compromised then someone can get the secret key that decrypts the
addresses using the pass key from the automated software that does the
decryption

My objective was not to provide a high grade of anonymity, rather to enhance
the functionality provided by existing anonymous services with privacy
enhanced mail. Specifically to avoid sysadmins reading your anonymous replies
which are often unsolicited and somewhat dubious or compromising. I think
it achieves the objective but is clearly not going to sustain a concerted
attack on the server by a knowledgeable assailant like the NSA or FBI or
their equivalents in this country.

To my knowledge, being very naive when it comes to encryption, the provision
of anonymity which does not depend on a particular site to do the remailing
(and is hence vulnerable as described) is much less straightforward, not to
mention inconvenient. Perhaps I am overlooking something obvious to someone
more knowledgeable.

david




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eli Brandt <ebrandt@jarthur.Claremont.EDU>
Date: Wed, 25 Nov 92 19:32:58 PST
To: cypherpunks@toad.com
Subject: RE: PGP on local machine
In-Reply-To: <58809.drzaphod@ncselxsi>
Message-ID: <9211260332.AA23057@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> From: "DrZaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
> >The comm program shoves the cyphertext into the uploadt editor to write your messages then
> you've just lost the whole reason for encryption.

I think what you're trying to say is that writing the message on an 
insecure machine gives it away.  This is entirely true, but it sure
beats giving away your secret key and passphrase.  People were saying
that they were unable to do their message editing locally -- if this
is an insurmountable limitation, you'd do well to limit your disclosure
to the one message rather than every secret you posess.  If you *can*
edit and encrypt locally, do it, of course.

> [drzaphod@ncselxsi.uucp]

   Eli   ebrandt@jarthur.claremont.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Wed, 25 Nov 92 19:38:08 PST
To: cypherpunks
Subject: Steve Kent on certification trust paths
Message-ID: <9211260338.AA23180@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Steve is one of the key folks in the Internet PEM project.  He sent this
message last month during a discussion of why PEM uses top-down
key certification rather than the "mesh" style that PGP uses.

I hope that our (cypherpunks) experience with mesh key exchange will
teach us a lot about whether and how it works.  Nobody has ever tried
this before, so we are doing research!

	John Gilmore

------- Forwarded Message

Message-Id: <9210212125.AA27956@TIS.COM>
To: Peter Williams <P.Williams@cs.ucl.ac.uk>
Cc: pem-dev@TIS.COM
Subject: Re:   Perhaps OSI security is not possible in a liberal community!
Date: Wed, 21 Oct 92 17:24:42 -0400
From: Steve Kent <kent@BBN.COM>

Peter,

	You have receibved replies from a couple of folks (via
pem-dev) who have expressed views on why a strictly hierarchic
certification system is not required.  As the author of the words you
cited in raising your question, and as an advocate of a strict
certification hierarchy, let me respond.

	It is clear that one can construct a certification system
which is not a tree, but rather is a mesh.  The PGP approach is an
example of such a scheme and X.509 permits this.  However, there are a
number of advantages to a hierarchy which have motivated its use in
the Internet:

	In a pure certification mesh, one acquires certification paths
by following chins of implied trust.  It is not at all obvious that
this approach scales well.  The PGP folks do not yet have significant
experience in this regard, so it will be interesting to see how the
mesh develops over time.  Most folks who have spent considerable time
exploring this issue believe that unbounded transitive certification,
with no required name relationships, is a bad idea.  The rationale is
that whatever trust one might accord to an entity may not apply
transitively.  I may give a house key to my neighbor to be able to
open my house under certain circumstances, but that does not suggest
that I would give the key to whomever that neighbor provides his key.
It seems difficult to characterize the nature of trust in these
"lateral" arrangements and applying trust transitively is even more
difficult.

	From a user interface standpoint, it is generally agreed that
most users are not capable of evaluating a certification path.  In PEM
we feel that a user should know the distinguished name (or an alias
assigned by the user locally) of a message originator/recipient, and
some indication of the policy under which the user was certified,
e.g., a short-hand name for the PCA.  This is about all we expect a
user to be able to deal with.  The though of a user really paying
attention to (much less applying meaningful value judgements to) all
of the DNs in a certification path boggles the mind.

	I won't clain to understand all the details of what PGP
provides for managing key rings.  However, if one were to provide a
management tool for mesh certification in general, I think it ought to
permit a user to construct a trust graph expressing the relationships
implied by certification paths he acquires.  The user might be able to
express a degree of trust and a level of allowed transitive
certification for each entity in the graph.  Disply of this info, to
allow a user to manage the graph, would be necessary.  All in all, it
seems to be pretty complex and it is highly questionable if most
(many?) users could make use of this facility without getting
confused.  But, this analysis is based on reasoned speculation, not
actual experience.

	The naming issues is a related, but somewhat indepedent topic.
DNs provide many good features for use with a certification system.
One wants the names to be globally unique and manageable in a
distributed fashion.  Being able to express a through, rich name is
important if this technology is ever to expand beyond casual use in
R&D environments.  Note that DNS names are not great choices.
Although there are close to a million DNS host names, that represents
a very small portion of the population that one wants to serve with a
system like PEM.  Most DNS names are very short and will eventually
reuslt in collisions as more individual and organizations are
registered.  The problem is worst in the U.S. where we have adopted a
parochial scheme with GOV, EDU, COM, ORG, and MIL at the top, vs.
other countries which prefix their DNS names with a country code.
What's worse is that many DNS indivdiual names are not very mnemonic
and thus don't offer much in the way of indentification outside of a
very narrow context.

	There is sometimes confusion about the role of certificates.
X.509 makes it clear that they serve only for identification, not
authorization.  This is improtant because it is difficult enough to
manage them for identification purposes without overloading
authorization info on them.  Also, the entities who grant
authorization may often be different from those who vouch for the
identity of an individual (or organization) and thus this independent
is appropriate.  Often there seems to be a desire to bind more info
into a certificate in support of authorization, but I (and many
others) believe this to be a mistake.  One can construct other
certificates (like the PACs EMCA has defined) to use public key
technology for authorization, leveraging off of certificates used for
identification.


	Finally, there is revocation.  We have adopted both a push and
a pull facility for CRLs in PEM and the PEM CRL format differs
slightly from that in X.509.  Many folks fail to appreciate the
subtleties of CRLs at first.  Hot listing on a CRL says that either a
key has been compromised OR a name has changed.  If we have
fine-grained, organizationally-related names, then these names will
change with some frequency and thus CRL entries will arise.  Because a
certificate establishes a binding between a name and a key, it seems
appropriate that only the entity which vouches for this binding (a CA
of some tyep) should be able to revoke it.  That is the model we use
in PEM and we add the important feature of having each CA advertise
when it will issue its next CRL, so that user's know when each CRL
they hold is obsolete.

	
	Peter, I hope this note helps explain the very terse words I
put in the PEM key management document.

Steve

------- End of Forwarded Message





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 25 Nov 92 20:07:06 PST
To: cypherpunks@toad.com
Subject: Sharp Wizard as a Crypto Dongle?
Message-ID: <9211260402.AA12908@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


All the interesting discussion of building RS-232 crypto dongles,
notably the proposal of Yanek Martinson, remind me of the idea kicking
around of simply programming a Sharp Wizard (or Casio B.O.S.S., etc.)
to do the same function.

(And eventually much of our critical encryption will likely be done on
more powerful devices like the Apple Newton, General Magic gizmo, and
Eo thingamajig.)

These devices have several advantages:

1. Cheap. $150 or less.

2. No construction required.

3. Not likely to have trapdoors or other limits, at least not in the
hardware, or in the units you buy today at your local electronics
superstore.

4. RS-232 connections for PCs, Macs, etc. (used to be as an add-on,
now often bundled with the units).

5. LCD display, keypad, etc. (some of the features Yanek was
envisioning in later models of his dongle).

6. A fairly slow CPU, but one which is well-integrated with the other
features (and which saves us the effort of designing and debugging).

7. Some have PCMCIA capabilities.

8. They can be used for other thingss when not being used as a dongle.

9. New versions of the software (e.g., PGP 3.21) can be added more
easily, I suspect, than in a custom-built RS-232 dongle.

10. It is unlikely the NSA, FBI, or Patent Office could "ban" such
devices, as they are already widely deployed. Only the specific
programs that make them act as crypto dongles would be "bannable," and
I doubt this could be enforced.

By the way, the same arguments could be applied to using cellular
telephones as the base for building/programming portable, personal
crypto devices. (An exciting talk at Hackers on mods to Oki 900
cellphones was an eye-opener.) I don't think an easy interface to
RS-232 ports exists, but I know some cellphones interface to computers
(the Oki 900 above sure did).

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tony@morgan.demon.co.uk (Tony Kidson)
Date: Wed, 25 Nov 92 15:47:31 PST
To: cypherpunks@toad.com
Subject: Re: The Cypherpunks Mail Project
Message-ID: <775@morgan.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


In message <9211251705.AA17774@soda.berkeley.edu> you write:
>
> It is also my suspicion that simple PGP decryption support is fairly
> straightforward, being mostly the ability to run a command on a block
> and replace the block with the output of the pipe.  

I'd like to chip in here, in my _very_ newbie way, that not 
everybody is running a unix system with the ability to pipe 
things between processes in so facile a manner. I access the net 
through a dial up from a MS-Dos machine running KA9Q software. My 
PGP is of the stand alone sort. I cannot easily get a new mailer 
to run on this system. Whatever protocol is decided upon, it 
would be useful if it were not too host-system specific.

[FX Crawls back under stone]

Tony
------------------+-------------------------------+--------------------------+
| Tony Kidson     |`morgan' is an 8MB  486/33 Cat-| Voice +44 81 466 5127    | 
| Morgan Towers,  |Warmer with a 670 MB Hard Disk.| E-Mail                   |      
| Morgan Road,    |It  resides at Morgan Towers in| tony@morgan.demon.co.uk  |
| Bromley,        |Beautiful  Down Town  Bromley. | tny@cix.compulink.co.uk  |
| England BR1 3QE |            -=<*>=-            | 100024.301@compuserve.com|
+=================+===============================+==========================+




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fen@genmagic.com (Fen Labalme)
Date: Wed, 25 Nov 92 21:41:23 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9211260518.AA01581@>
MIME-Version: 1.0
Content-Type: text/plain


On the issue of digital cash and remailers

tcmay writes:
>Banks, escrow services, etc. will all have "reputations"...

Note that a good reputation is good as gold.  Now, when I get my remailer up
and running, I'll run it for a while in "free mode" (while I get the bugs out)
and then I'll put it into "reputation sharing mode" which works as follows:

Every time I get a message to be re-mailed, I remember the sender's site
name.  Later, when I desire to mail something, I may choose to send it through
that site.  If operating in free mode, it passes through.  If it is not a
remailer or doesn't accept my message (via a bounce) I take it off my list
of friendly mailers and and begin bouncing messages that it sends to me. 
This should, of course, all happen automagically.

I realize that I am describing this somewhat poorly (it's late and I'm tired)
but the basic concept is to get everuyone who wants to send mail through a
re-mailer to become a remailer, or perhaps buy "friendship" with one
through external means.  This propogates remailers.

The simplest form of barter is one for one.

Fen





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Wed, 25 Nov 92 22:23:39 PST
To: uunet!ghsvax!hal@uunet.UU.NET
Subject: An easy-to-reply anonymous mail scheme
In-Reply-To: <9211252352.AA01919@nano.noname>
Message-ID: <9211260605.AA04591@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


The only solution (and I think I mean ONLY) is positive filtering.
When pseudonyms proliferate, the only way to cut down on trash is by
filtering based on reputation.  Since negative reputation can be
avoided simply by creating another pseudonym, the only reputation that
will make a difference is positive reputation:  credibility.  

An example system would be one in which I give credibility and
transitive credibility ratings to all the names whose posts I want to
see.  The transitive part lets me discover new people (who know
people I respect who know people they respect...).  Then anyone
credible can introduce someone else around simply by deciding to read
their mail (assuming their taste is good enough that people want to
read what they're reading).

This grows in several directions: AI, reputation services (magazines),
etc.  A public system with pseudonyms will require this very quickly.
Reputation systems only work if things are digitally signed, of course
(so readers and filters can't be spoofed).

I will be talking about this more at the next cypherpunks meeting.

dean





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Wed, 25 Nov 92 22:38:29 PST
To: uunet!netcom.com!tcmay@uunet.UU.NET
Subject: Electronic Banking
In-Reply-To: <9211252219.AA00550@netcom.netcom.com>
Message-ID: <9211260619.AA04606@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


Currencies will almost certainly have to be backed by goods in order
to be astablished.  Would you want to keep your money in something
that could collapse easily?  There's been a lot of thought put into
using things like mutual fund shares as the currency.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 25 Nov 92 19:29:33 PST
To: cypherpunks@toad.com
Subject: advantages of RS-232 based crypto device
Message-ID: <9211260329.AA12665@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


A number of people responded, both privately and publicly to my RS-232
dongle idea.  Several offered help with the hardware/schematics
design.

Some thought that PCMCIA cards would be better for this.
Theoretically, yes.  They could contain more memory and processing
power in a smaller space.  There are several problems with PCMCIA.
First, not nearly as many devices have PCMCIA interface as RS232.
Second, you can not make a PCMCIA card yourself, nor can you easily
open it and look what's inside.

My proposed design would consist of only off-the-shelf parts, the
schematic would be published, so anybody could build the device for
himself.  I might distribute it in the kit form, which would include
all the parts and the PCboard, and a case.  This way, you can test each
component in any way you want, and then put the thing together by
yourself.  Even if you got the complete unit from me, you could open it
up, and look inside.  You could see if it actually corresponds to the
schematic.

Some people doubted the possibility of its second greatest advantage,
the ability to work with any computer or terminal regardless of
operating system, mail software, comm software, etc.  Also it could be
used between an ASCII terminal and a (non-trusted) host.

Here is an example of a design that I think will work with any
software/host/terminal/etc combination.  If I am wrong, please let me
know.  NOTE: this is not the final design of the device, just an
example.

=====================================================================
Since the device needs to have a processor anyway, it may as well have
a built-in simple line-mode editor that is good enough for composing
mail messages.  So to use the device to send mail, you would:

1.  Give the mail command to your host (or BBS) using whatever command
or menu selection you normally use to send mail.  Then if the mail
program puts you into a mode-based editor like vi, enter insert mode
(press i or a).

2.  Push the "encrypt" button on the device (or send a magic sequence
from your terminal).

3.  Type your message in a simple BBS style (in case you have not used
a BBS, this is the kind of editor they usually use:  You simply type
text. Every line has a number. When you press return, the next line
number appears.  At the beginning of a line, you can issue commands for
example with a slash or a dot. commands include things like DONE,
ABORT, DEL LINE, INSERT, etc.)

If you had the text prepared on the local machine, you could simply
transfer the text, and then type the "DONE" command.

All this while, the text is only stored in the memory of the crypto
device, the remote host is still waiting for input.  So plaintext never
crosses the line or network.

4.  When you are done, the text would be encrypted (you would select a
public key from the keyring, or it could be automatically determined
from preceding text (such as the e-mail address).  You would have the
option of signing the text.

The device transfers the encrypted text to the host and becomes
transparent.

You then type the command to tell the host that you are finished typing
the message, and off it goes!

==========================================================================

Now, if you see any reason why the above would not work, please let me
know.

A number of people wondered if the tamper-proof memory for private key
storage was necessary.  Some other people wondered if it was in any
way effective (i.e. if someone gets the device, they can just use it to
decrypt/sign stuff; so what if they don't get they actual key out of
it).

I tend to agree. I will have to think some more about this.

It would certainly make the design much simpler (and cheaper, and
consistent with the desire for off-the-shelf parts) if I avoid use of
such exotic hardware.

The private key may be protected from use by un-authorized users by
encrypting it with a key, and requiring it to be entered on a keypad on
the device.  Someone suggested that the key must be typed in
periodically (every x minutes).

The only case I could see a problems with this approach is if "they" get
you while you are using the device. For the next x minutes they can
decrypt any old messages they may have stored.

I believe this addresses all the concerns that have been voiced about
this device.  If you have any other concerns, questions, or comments,
please let me know. 

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 25 Nov 92 19:36:50 PST
To: cypherpunks@toad.com
Subject: neat features that could be added to the crypto dongle
Message-ID: <9211260336.AA12812@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


Here are some neat ideas: 

If you and me both had one of these devices, we could connect them, and
exchange our public keys.  We could also exchange other public keys on
our keyrings.

Another useful thing it could do: watch the incoming rs-232 traffic for
anything that looks like a public key.  When one is detected, you would have
the option of storing it on your keyring.

It could have an LCD display, and then it could calculate a hash function
of someone's public key and display it.  This would make it easy to 
verify keys by phone or any other means.  Instead of spelling out the 
130-character alphanumeric sequence you would only need to verify a 
short (maybe about 8 to 12 digits) number.  

As someone mentioned, if something has a keypad and an LCD display, it can
also be a calculator. 

And, if it has two RS-232 ports it could be a break-out box or a line 
analyzer.

But I think this is creeping featurism.

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Wed, 25 Nov 92 23:12:31 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9211260713.AA01656@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


This entire business may be pretty simple.  If we have anonymity
both ways, (where one or neither party knows the others physical
location), then who cares about the content of the message? 
 
You might as well send it in plain text,  Except you need RSA
just for the signitures so you know you aren't being spoofed.

*RSA signatures ARE money.*

Unless money (accouting, proof) is needed, you don't need RSA.

What you do need is anonymity. {Of course throwing RSA on top
of it with RSA encoded regular keys is a nice touch (no sense in giving
anything away.)}

----

Now listen up kiddies, what you are playing with is sedition,
conspiricy, and the like.  In other words plain old politics.
Adding mumbo-jumbo (crypto) technology doesn't change a thing.

If you want to do this, it is a simple matter of building a large
enough cooperative group.

How big?  Well bigger than the Hells Angels, Maybe a thousand
people.  I don't know.  Depends on how rough it gets.

But the proceedure is just mutual backscratching.  We all accept
and forward anonymous mail for each other.  So long as it is coded,
we can deny knowledge of the contents.  That can go a long way as
long as the basic activity (of forwarding) itself is not proscribed.

There have been several suggestions here how this would be done.

You send mail to a cooperative site, who forwards it.  That same site
will receive replies.  You collect your mail with specific commands to
dump the accumulated contents to some other node.  It would be moderately
tough to bug one node.  A quick second skip would make it almost 
impossible to track, 3 quick skips to eternity.

But the trick is to have a large net of standardized, cooperating sites.

There have been suggestions to throw cypher-money into this equation
to pay for the operation of the "MIXes" or the operators of the servicing
nodes.  But that won't work.  In a hostile environment money won't
buy civil disobedience.  It's like you can't pay somebody else to
go to war for you.  We all have to shoulder part of the risk.  We should
evolve some standard "remailer/replier daemon" and run them as a common
service.  It is just our civic duty.

The list of cooperating, volunteer sites would be published in a plain
text group.  You are either on the list or you aren't.

Just the presence of such a cypher mob should stop the forces of darkness.

-Gilbert






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 25 Nov 92 20:47:27 PST
To: cypherpunks@toad.com
Subject: using personal organizers or palmtops for crypto
Message-ID: <9211260447.AA14645@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain



> notably the proposal of Yanek Martinson, remind me of the idea kicking
> around of simply programming a Sharp Wizard (or Casio B.O.S.S., etc.)
> to do the same function.

I have thought of that before.  Actually, I was thinking of using a notebook
computer with 2 serial ports as a prototype/proof of concept.

> These devices have several advantages:

True. But there are also disadvantages:

They generally don't have two serial ports.  This may not seem like much,
but is actually a serius problem.  Since they tend to have small screens,
weak keyboards, and not the greatest comm software, you might not like
using it as your window into the cyberspace.  The advantage of a standalone
device with two rs232 ports is that you can continue to use your existing
terminal, pc or a mac, along with all its conveniences.

> 1. Cheap. $150 or less.

I hope to make my device in this price range or less.  I can not be sure yet
because I don't have a definite hardware design completed, but that is the
range I am aiming for.  I don't know, maybe I am unrealistic, but I think
that in kit form it could be significantly under $100.


> 2. No construction required.

If this idea ever takes off in a big way (about a hundred orders or so) then
I have an electronics company that could build them for me.
 
> 3. Not likely to have trapdoors or other limits, at least not in the
> hardware, or in the units you buy today at your local electronics

While they may not have any intentional trapdoors, since you don't have
the full design specs, you can never be sure of everything that is going on
within the machine.  For example, if in my device I have a section of memory
that holds the private key, and I clear it (overwrite with nulls) then I
can be reasonably sure that if someone was to get the device they would
not be able to retrieve the private key from anywhere.  In a machine such 
as a Wizard, you never know where the number may end up, for example in 
some area of memory used for the auto-resume feature or some kind of
cache.  If a device was not designed with security in mind it is likely
to be insecure.

> 6. A fairly slow CPU,

Might severely limit the length of keys you can handle, therefore the 
level of your security.

> 7. Some have PCMCIA capabilities.

See my previous post on why PCMCIA is not a very good choice of technology
for this purpose.

> 9. New versions of the software (e.g., PGP 3.21) can be added more
> easily, I suspect, than in a custom-built RS-232 dongle.

I plan to build it as a generic processor with two RS-232 ports.  All the 
crypto stuff would be handled in software.  So to cope with new formats,
etc. all you would need to do is reprogram the EPROM.

This is completely unrelated to the topic at hand, but:

> By the way, the same arguments could be applied to using cellular
> telephones as the base for building/programming portable, personal
> crypto devices. (An exciting talk at Hackers on mods to Oki 900
> cellphones was an eye-opener.) I don't think an easy interface to
> RS-232 ports exists, but I know some cellphones interface to computers
> (the Oki 900 above sure did).


What interfaced to the computer was the control functions (dial, signaling,
etc.) It sure was fun and useful, but not nearly enough to make a secure
telephone.  The actual speech (that which you are trying to encrypt) is
never actually digitized....


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tony@morgan.demon.co.uk (Tony Kidson)
Date: Thu, 26 Nov 92 01:30:46 PST
To: cypherpunks@toad.com
Subject: Re: Electronic Banking
Message-ID: <782@morgan.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


In message <9211252219.AA00550@netcom.netcom.com> you write:
>
> Warning! Recently, a bunch of bowlers (women, no less) were busted for
> illegal gambling because of their "pot" they were bowling for. After
> much public outcry and laughter at the authorities, the charges were
> either dropped or reduced. I mention this because casual bowlers evoke
> sympathy, hackers and cypherpunks do not.

Using the net, the 'banker' could easily be 'offshore' and not 
subject to US law in these matters. After all the internet 
reaches into Canada and obviously (from my point of view) to the 
UK.  I think a more real problem with anonymous banking, is not 
one of 'trust' in the 'banker' but in his net access. What do you 
do when your banker, for whatever reason, becomes unreachable?


Regards


Tony
------------------+-------------------------------+--------------------------+
| Tony Kidson     |`morgan' is an 8MB  486/33 Cat-| Voice +44 81 466 5127    | 
| Morgan Towers,  |Warmer with a 670 MB Hard Disk.| E-Mail                   |      
| Morgan Road,    |It  resides at Morgan Towers in| tony@morgan.demon.co.uk  |
| Bromley,        |Beautiful  Down Town  Bromley. | tny@cix.compulink.co.uk  |
| England BR1 3QE |            -=<*>=-            | 100024.301@compuserve.com|
+=================+===============================+==========================+




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill Sommerfeld <sommerfe@orchard.medford.ma.us>
Date: Wed, 25 Nov 92 21:38:50 PST
To: tcmay@netcom.com
Subject: Sharp Wizard as a Crypto Dongle?
In-Reply-To: <9211260402.AA12908@netcom2.netcom.com>
Message-ID: <9211260511.AA00154@orchard.medford.ma.us>
MIME-Version: 1.0
Content-Type: text/plain


I had the same idea, only with an HP48SX (I work for HP); the 48 is a
little pricier, but cheaper than say the 95LX or similar pocket PC's.

(I got as far as a DES implementation in user RPL -- I "ported" the
Ferguson DES in a day or so; I haven't gotten around to slogging
through converting it into system RPL or machine code).

Progammable consumer products would be pretty good as *prototypes*,
but not good enough for "production" use in the presence of a
determined attacker due to lack of tamper-resistance.

[my apologies if this came up before; I'm new to the list].

					- Bill




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Wed, 25 Nov 92 05:24:15 PST
To: cypherpunks@toad.com
Subject: Secure PK swapping.. what are the methods?
Message-ID: <9211251323.AA27604@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain



Below is a letter Ive sent to a person designing a communications system
similar to IRC but designed with the ability to be anonymous and as secure
as possible. Further details will be announced soon when it's stable.


--------------------Begin letter----------Begin letter-------------------

Before you get too involved with the client in the comm system I was thinking
of a way of having secure privmsgs, two forms depending on how open one chose
to be:

Messages are exchanged via UDP to hide from the netstat junkies...

When someone does a msg the first time and the client doesnt know about
that user it queries the server to either get a hostname/port pair for
that user and/or a public key. The data is then stored in an internal
attribute bank.

   Format of a private message:

   ._________________________________________________________.
   | Nickname Plaintext     |  dest IP    |  dest udp port   |
   | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= |
   | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= |
   | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= |
   `---------------------------------------------------------'
   [Return host/port/public key are encrypted into the PGP? message]
   The above message is then sent to the delivery module of the client.

   The above host and port are either the recipeints or the server's depending
   on what type of message is being sent. Thus the same message can go to the
   server or the recipient direct per se:

1) Using the hostname/port + public key for that user the sender's client
   encrypts the message and udp transmits a message to that port on the other
   users host. That remote client has set up a socket to listen on that udp
   port for messages. The remote client unpacks the message with it's private 
   key and extracts the message, a reply host and port and the senders public
   key. He can then reply to the sender and they both can talk without
   loading down the server. Plus, unless someone is logging the ethernet,
   no one can ascetain wether they are talking. There is only the initial
   request of the users public key from the server which each client sends
   in automatically when it connects. You might also have an option in the
   client to auto download a block/all of the users nicks and their keys so 
   no-one can detect the initial query of a user.

2) The other, differently secure :), form is because the server has been told
   to hide the users username + hostname from the /who information. All there
   exists for that person is a nickname and a public key. The senders client
   gets individually/block downloads the key he wants and proceeds to udp
   a message to the server which has the udp port and hostname of the
   recipient as normal from the client connect. It acts as IRC does now, as
   a middle man for messages. Less secure because the server admin can 
   ascetain that there is a message being sent between the two people and
   also he can slip in his *OWN* keys to basically grab and decipher messages
   between the two parties. i.e he sends his own key to the sender and
   decrypts the incoming message and then sends the message out to the
   recipient using their encryption key. neither user could tell there was a
   switch in between. (There are schemes to get past this however).

Both ways have their flaws because you are relying on the non-hackedness of
the server to give you the right keys and hostnames and ports. A bad admin
could easily, knowing enough about coding, disrupt the entire process if we
didnt from the start ensure the right protocols were used. It has to be done
right the first time or not at all.

I'll echo this letter to a cryptography mailing list to ask for details of
schemes that will allow each user to know they have a valid, secure public
key of the other.

One possible solution would be to do a mass query of all the online servers
at once and if they didnt report the same keys sound a Real Big Alarm (tm).
Maybe an automatom could sit there randomly checking keys :) (Can hear the
cries of "No Bots.. No Bots" now :). (Note this allows *someone* to know your
doing a query for a user... that may or may not bother the sender/recipient.
Doing a block transfer from all the servers at once isnt net.nice)

Comments?

------------------End of Letter----------------End of Letter----------------

Now what Im curious about is any other methods of secure key exchange where
the exchange mid point may be lying about the keys, the hosts and the ports.
Assume each person knows the others 'style' etc. How does one get the real 
keys to each other with an unreliable "medium"? (It might slip in it's PK).
Assume that they havent previously organised a key exchange.

Replies to me or the list.. (but not both please.. my mbox is busy enuff :)

Mark
mark@coombs.anu.edu.au




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: rebma!rebma!wmo@kksys.mn.org
Date: Thu, 26 Nov 92 00:22:10 PST
To: cypherpunks@toad.com
Subject: Remailer at rebma
Message-ID: <m0mudcP-0006TAC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


I've got Hal's PGP mods to the remailer code installed on rebma.

The remailer is remailer@rebma.mn.org, and the PGP key to use is:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD
WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b
yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR
tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKQ==
=/qHx
-----END PGP PUBLIC KEY BLOCK-----


See Hal's previous messages for how to use the remailer, or write me, and
I'll dig his messages up.

I liked Fen's idea about bartering remailers.  I'm all for it.

-Bill
-- 
Bill O'Hanlon						 wmo@rebma.mn.org





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: rebma!rebma!wmo@kksys.mn.org
Date: Thu, 26 Nov 92 00:22:31 PST
To: cypherpunks@toad.com
Subject: MIME
Message-ID: <m0mudhV-0006TAC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


I got the metamail stuff running on my machine.  I think it's a good way to
get the multimedia mail job done.

Does anyone on the list have a better .mailcap entry for pgp than the 
following....?

application/pgp ; pgp < %s ; label="PGP encrypted text" ; compose="pgpcompose %s"

where pgpcompose is a quick hack that looks like:
#!/usr/bin/ksh

rm /tmp/pgpcompose
vi /tmp/pgpcompose
echo What key?
read key
pgp -mae /tmp/pgpcompose $key
mv /tmp/pgpcompose.asc $1
exit 0

I've just been fooling around with metamail for a couple days, and I don't
know what the best way to include PGP is...  This seems to work, but I'm
guessing I'm missing something more elegant.

-Bill
-- 
Bill O'Hanlon						 wmo@rebma.mn.org





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Thu, 26 Nov 92 01:37:40 PST
To: cypherpunks@toad.com
Subject: Mac PGP report and Rander progress
Message-ID: <9211260933.AA04417@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Mac PGP effort:

   After talking with Phil Zimmerman,   we decided to break the
MacPGP effort into two teams.   A short term team as it currently
stands now,  with the origional members,   and a long term team to
change PGP into a set of C Libraries that can be used with ANY
platform or API.   The short term team consists of its current
members who are doing current work on the Mac implementation.

   Next week,  perhaps on Wednesday Evening at 7 pm,  we will be
setting up a conference call to talk about all of the details,
and introduce each other.    My role in this currently will be
that of Email coordinator between the Mac PGP effort and the
other platforms.

   It is obviously clear that there is still a lot of mis-trust
that people have in me.     I guess it's still very hard to ditch
that "Once a criminal- always a criminal" attitude.

Phil Karn says:

>John Draper was proposing to manufacture rs232 random number
>generators -- would you buy a used random number from this man?

   This is EXACTLY my point.   So I WILL be publishing the schematic
and I expect the Rander box will be put through it's paces.   I have
simplified the circuit immensly,  and even eliminated the AD converter,
but not sure the design works,  but want to run the design by a few
other HW types before I "breadboard" it.    I think I got it down to
3 chips including the UART.   Two CMOS chips,  a Latch and a gate I'm
using as a comparitor,  and the UART plus a noise source.    Gack!!
All these years I try and ELIMINATE noise,  and now I am LOOKING
for noise.   By biasing one of the gates,  into the linear mode,  it
doubles as the amplifier for the noise source.   I've gone eligantly
simple with the design,   I just hope it works.   Perhaps this circuit
can be integrated into Yanek's Dongle.

Phil K. writes:
>>My thinking is to limit the external "dongle" to the one function that
>>is truly sensitive and worthy of special protection: RSA secret key
>>operations.

Eric Hughes replies:
>Phil's comment are right on.  There is a need for you secret keys
>to be easily and physically relocatable.

The Obvious,  cheapest,  but perhaps not the best way,  is to keep
your key on a floppie.


More later ....




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Thu, 26 Nov 92 02:43:35 PST
To: miron@extropia.wimsey.com
Subject: Re: How far is to far?
Message-ID: <199211261042.AA23055@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Miron Cuperman responds to my concerns about the IRS's claims on barter
systems by saying, "How do you think the IRS is going to trace those banks
and customers behind all the anon mixes?"

I must really disagree here.  If we start sneaking around in the shadows of
legality, we will eventually bring down some nasty attention which will not
help us.  Privacy itself is a mainstream issue.  Dumping all forms of taxes
is not a mainstream issue, in fact the mainstream regards tax resisters as
fringies of the worst order.  This is not to debate the merits of the
substantive issues involved, just to recognise the major PR problem which
exists and say I believe we should stick to the main issue.  I for one don't
want the Feds to have an excuse to lock up the whole net or our little
fragments of it.  

We can minimise taxation and stay completely within the law by operating as
a volunteer not-for-profit network.  And then if the Feds come down on us
for using unregistered crypto keys, we have a new issue that the public
haven't become jaded over, which can be made much of in the media.  

And I would also say that it's not good to give potential adversaries an
excuse for saying we're doing crypto simply in order to hide illegal
activities such as "tax cheating" or whatever; next it will be dope and
kiddie porn and bank robbery via ISDN, eh...?

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Thu, 26 Nov 92 02:55:00 PST
To: ebrandt@jarthur.Claremont.EDU
Subject: Re:  PGP on local machine (was Re: MacPGP)
Message-ID: <199211261053.AA23687@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Eli discussed some ideas regarding online encryption... it suddenly occurred
to me that if you were connected to the phone line while doing your crypto
processing, it's entirely possible that some signal would leak through and
if your phone line was being monitored, the nastie-wasties would get the
whole thing including your private key.  Uh-oh, very bad.  Thus the need for
some kind of hardware device which isolates the line and all that.  Perhaps
a specifically cryptographic modem as has been proposed by others here.  And
perhaps a tweak in the software which requires that the user set these
options manually at some point, where a warning message would occur to say,
"don't do on-line crypto unless you have (one of the protected modems)."

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Thu, 26 Nov 92 03:17:22 PST
To: tcmay@netcom.com
Subject: Re: Electronic Banking
Message-ID: <199211261116.AA24529@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Tim and others write with concern about the possible legal consequences of
setting up a model digital economy.  I would like to suggest that there may
be very little to worry about here.  This entire project constitutes a
research exercise which will no doubt be written up for publication (at
least online publication, which makes sense culturally given the nature of
the community of interest).  It's research and education.  The amounts of
"digital money" involved can be utterly miniscule: pennies.  This is a
"token economy" in the same sense as when psychiatric hospital inmates work
on the ward for tokens they can trade in for snacks and so on, or a
highschool economics class does a similar exercise using Monopoly-type play
money.  

This is not illegal any more than any other social science project would be
illegal if all the subjects were adults giving informed consent.  Pennies
are not a controlled substance nor are they a weapon (unless dropped on
people from high places... :-).  

By analogy I'm thinking of the laws against bigamy/polygamy, and a group of
adults getting together to study the question of the effects of different
kinds of marital arrangements.  So they have a group where they "pretend" to
carry out different arrangements and then examine the social dynamics
resulting from each.  

It's quite obvious we're all concerned about the larger social impacts of
the possibility of a transition to a cashless economy; and we're
hypothesising possible negative consequences and trying to work out
solutions.  That is entirely admirable, and can be presented as such to
anyone who cares to listen to the case.  

If this needs any further work to develop research angles, I'll gladly come
up with a bunch of surveys and other measures, and we can put them into use
and harvest some nifty statistical results which might be publishable in the
academic literature.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Thu, 26 Nov 92 03:24:33 PST
To: yanek@novavax.nova.edu
Subject: Re:  RS232 Crypto Dongle (idea for widely accessible crypto technology)
Message-ID: <199211261123.AA24844@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Re Phil's items on the Crypto-Dongle.  

I'm in favor of a device having a keypad for PIN entry, with a fail -->
destroy function.  Making it small enough to be kept on one's person all the
time, virtually guarantees other manufacturing compromises which would
result in degraded reliability or increased potential for physical breakage.
 It should not be necessary to carry it on you; in any case, possession of
one might raise eyebrows in some quarters.  I believe that carrying out the
entire crypto operation in the dongle is preferable to having it only do the
secret key RSA processing; if for no other reason, compatibility problems
that might result in creation of platform-specific dongles.  Better to have
one Universal Dongle that needs only a platform-specific user interface.  

The dongle (suggested brand name: Codepack) could also be sold as a sort of
blank slate into which a user would load his preferred crypto software.  Now
we have a generic product which can be sold over the counter without
prescription, as it were. 

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Postmaster <Postmaster@UCS.Cam.AC.UK>
Date: Thu, 26 Nov 92 00:34:19 PST
To: cypherpunks@toad.com
Subject: Failed Fail Report
Message-ID: <A6A6A8C8EF028610@UK.AC.CAMBRIDGE.PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain


The enclosed fail report failed to reach it's intended recipient because of the
use of the unbracketed IP number.  HOWEVER, surely there should be a -request
address for cypherpunks to which should be in the Sender: field so that fail
reports go back to the list maintainer and not the originator of the article.

Tim Brooks
Postmaster(@uk.ac.cam.ucs, @uk.ac.cam.phx, @uk.ac.cam.cus, @uk.ac.cam.ppsw)
Postmaster(@ucs.cam.ac.uk, @phx.cam.ac.uk, @cus.cam.ac.uk, @ppsw.cam.ac.uk)

University of Cambridge Computing Service Tel: 0223-334709, Int: +44 223 334709
New Museums Site                          Fax: 0223-334678, Int: +44 223 334678
Pembroke Street                           Telex: 81240 CAMSPL G
CAMBRIDGE                                 E-Mail(JNT): T.Brooks@UK.AC.Cam.UCS
CB2 3QG  United Kingdom                   "(Internet): T.Brooks@UCS.Cam.AC.UK
X.400: /I=T/S=Brooks/OU=Computing-Service/O=Cambridge/PRMD=UK.AC/ADMD= /C=GB/

> Accepted:  17:57:03 25 Nov 92
> Submitted: 17:29:12 25 Nov 92
> IPMessageId: <"ppsw1.cam..157:25.10.92.17.28.53"@ppsw.cam.ac.uk>
> From: MAIL-DAEMON <postmaster@uk.ac.cam.ppsw>
> To: FAILREPTER@uk.ac.cam.phx
> Subject: Delivery Report (failure) for fnerd@192.9.200.3

> Received: from ppsw.cam.ac.uk by ppsw1.cam.ac.uk id <05165-0@ppsw1.cam.ac.uk>;
>           Wed, 25 Nov 1992 17:29:12 +0000
> Message-Type: Delivery Report
> Content-Identifier: Fail Report

>
> ------------------------------ Start of body part 1
>
> This report relates to your message: Subject: Fail Report,
>   Message-ID: <A6A5DE7C97F29040@UK.AC.CAMBRIDGE.PHOENIX>,
>   To: fnerd@192.9.200.3
>         of Wed, 25 Nov 1992 17:28:52 +0000
>
> Your message was not delivered to   fnerd@192.9.200.3
>         for the following reason:
>         Unknown Address
>         Unknown domain '192.9.200.3'
>
> ***** The following information is directed towards the local administrator
> ***** and is not intended for the end user
> *
> * DR generated by: mta ppsw1.cam.ac.uk
> *         in /PRMD=UK.AC/ADMD= /C=GB/
> *         at Wed, 25 Nov 1992 17:28:53 +0000
> *
> * Converted to RFC 822 at uk.ac.cam.ppsw1
> *         at Wed, 25 Nov 1992 17:29:12 +0000
> *
> * Delivery Report Contents:
> *
> * Subject-Submission-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<A6A5DE7C97F29040@UK.AC.CAMBRIDG]
> * Content-Identifier: Fail Report
> * Subject-Intermediate-Trace-Information:  /PRMD=UK.AC/ADMD= /C=GB/arrival Wed, 25 Nov 1992 17:28:52 +0000 action Relayed
> * Subject-Intermediate-Trace-Information:  /PRMD=UK.AC/ADMD= /C=GB/arrival Wed, 25 Nov 1992 17:28:40 +0000 action Relayed
> * Content-Correlator: Subject: Fail Report,
> *                   Message-ID: <A6A5DE7C97F29040@UK.AC.CAMBRIDGE.PHOENIX>,
> *                   To: fnerd@192.9.200.3* Recipient-Info: fnerd@192.9.200.3,
> *         /RFC-822=fnerd(a)192.9.200.3/OU=PP Switch/O=Cambridge University/PRMD=UK.AC/ADMD= /C=GB/;
> *         FAILURE reason Unable-To-Transfer (1);
> *         diagnostic Unrecognised-ORName (0);
> *         last trace (ia5 text (2)) Wed, 25 Nov 1992 17:28:40 +0000;
> *         converted eits ia5 text (2);
> *         supplementary info "Unknown domain '192.9.200.3'";
> ****** End of administration information
>
> ------------------------------ Start of forwarded message 1
>
> Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk
>           with NIFTP (PP-6.0) Cambridge as ppsw.cam.ac.uk
>           id <05157-0@ppsw1.cam.ac.uk>; Wed, 25 Nov 1992 17:28:53 +0000
> Date: Wed, 25 Nov 92 17:28:40 GMT
> To: fnerd@192.9.200.3
> From: Mail Server <FAILREPTER@uk.ac.cam.phx>
> Subject: Fail Report
> Message-ID: <A6A5DE7C97F29040@UK.AC.CAMBRIDGE.PHOENIX>
>
> Your message was not delivered to one or more of:
> LI10000@uk.ac.cam.phx
>
> Recipient has too many outstanding messages in message store: 'LI10000@UK.AC.CAM.PHX'
> No valid recipients in JNT header
>
> Failed message follows:
>
> Received: from relay2.UU.NET by ppsw1.cam.ac.uk
>           with SMTP (PP-6.0) International as ppsw.cam.ac.uk
>           id <05143-0@ppsw1.cam.ac.uk>; Wed, 25 Nov 1992 17:28:32 +0000
> Received: from toad.com by relay2.UU.NET
>           with SMTP (5.61/UUNET-internet-primary) id AA07054;
>           Wed, 25 Nov 92 12:20:09 -0500
> Received: from cygnus.com by toad.com id AA12348; Wed, 25 Nov 92 09:17:33 PST
> Received: from relay2.UU.NET by cygnus.com (4.1/SMI-4.1) id AA26873;
>           Wed, 25 Nov 92 09:17:10 PST
> Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET
>           with SMTP (5.61/UUNET-internet-primary) id AA05539;
>           Wed, 25 Nov 92 12:15:15 -0500
> Received: from smds.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail)
>           id 121431.10955; Wed, 25 Nov 1992 12:14:31 EST
> Received: from waldo by smds.com (4.1/SMI-4.1) id AB05506;
>           Wed, 25 Nov 92 11:29:04 EST
> Message-Id: <9211251629.AB05506@smds.com>
> Sender: fnerd@192.9.200.3
> Date: Wed, 25 Nov 1992 12:40:24 -0800
> To: cypherpunks@com.toad
> From: fnerd@com.smds (FutureNerd Steve Witham)
> Subject: Re: Random Numbers Boxes and Cypher Processers
>
> >Why do encryption in the modem instead of the host cpu?
>
> A point that hasn't been made painfully clear yet: "DSP--Digital
> Signal Processor" chips are really just fast processors for repetitious
> arithmetic--just what RSA needs.  Maybe some experience in
> programming them for that sort of purpose would be useful.
>
> - -fnerd
> fnerd@smds.com (FutureNerd Steve Witham)
>
>
> ------------------------------ End of forwarded message 1






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: richard_mezirka@askinc.ask.com (Rich Mezirka)
Date: Thu, 26 Nov 92 09:24:21 PST
To: gnu@cygnus.com
Subject: Re: Electronic Banking
Message-ID: <9211261718.AA28906@askinc.ask.COM>
MIME-Version: 1.0
Content-Type: text/plain


IRS regulations related to 1099-b and 1099-misc make it LEGAL providing
all parties and the BANK file with the IRS. Bank MUST file when over 100 transactions per
year are recirded. Individuals must file each transaction. Add some rules
for mandatrory electronic filing when movre than 500 (I think that's the limit)
transactions are posted. ZAdd another hassle with mandatory 20% of value
must be withheld and filed with IRS inlieu of taxes...
(reference 1992 IRS publication on 1099 processing, pages 10-12... pub
number available on request)(I left my copy at the office).

As I told Tim, this smack s of Al Capone like harassment... "We'''
make it WORSE if we catch you" BUT I have personal experience with IRS
in 1980, 81, 82 as they attacked barter (I designed and developed
software for an electronic settlement system for Trade Systems Corporation
in San Jose; we did about 4 million/year unitl the IRS audits startedf and
then all big players got tax attacked). for those without experience with
our IRS, remember they do not live within our regulary judiciary
(innocent until proven guilty) system with  open courts... they seize
first and have a closed hearing system underwhich you get to negotiate
a settlement to get YOUR stuff back, maybe. (references available upon 
request). They use local marshalls with large guns and IRS judical
orededers to tsake what everthey thiink they are due.

Again, as I told Tim, we should continue our public discussion of the
principles we hold dear and continue our efforts at preventing further
erosion. We should also be very careful about stepping on the dragons'
tails until we are privacy protected... principlesa nd theorey public,
practice and tactics private.

spreading the sanity, quietly
Rich




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 26 Nov 92 07:21:57 PST
To: tribble@xanadu.com  (E. Dean Tribble)
Subject: Re: reputation
In-Reply-To: <9211260605.AA04591@xanadu.xanadu.com>
Message-ID: <9211261521.AA26207@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> filtering based on reputation.  Since negative reputation can be
> avoided simply by creating another pseudonym, the only reputation that
> will make a difference is positive reputation:  credibility.  

What's to stop you (once you have some "reputation") from creating 250
other pseudonyms or "identitites", giving them all a "reputation", and then
create another identity, and have these 250 all give this one as much as
possible, in effect creating an identity with a lot of "credibility" out
of thin air?


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 26 Nov 92 07:54:44 PST
To: cypherpunks@toad.com
Subject: Re: PGP on a multiuser system
In-Reply-To: <m0mudhV-0006TAC@rebma.rebma.mn.org>
Message-ID: <9211261554.AA26688@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> where pgpcompose is a quick hack that looks like:
> #!/usr/bin/ksh
> 
> rm /tmp/pgpcompose
> vi /tmp/pgpcompose
> echo What key?
> read key
> pgp -mae /tmp/pgpcompose $key
> mv /tmp/pgpcompose.asc $1
> exit 0


This is not a very good way of doing this unless this is on a single-user
linux system where youhave read all the source, and compiled it yourself.

First, if on a multi-user system, what happens if two people run pgpcompose?

At the very least, use code like "vi /tmp/pgpcompose.$$", which will append
your process ID to the temp file name.

It is NOT a good idea to keep the plain text in a disk file, even for a little
while.  It would be very easy for someone to set up a crontab entry which 
looks for files of the name /tmp/pgp*, and copies them to a hidden directory.

You would never even know that it was happening.

If you absolutely MUST do crypto on a multiuser machine, at least try not to
keep plaintext or private keys in files.  

For example, you could instead rewrite the above script to call vi directly
on what will become the output cyphertext file.  Then the user types in
plaintext, and does not save the file.  The file (while still only in memory)
is piped (!G) through pgp by the user.

This is still not very secure, since it would be not too difficult for someone
to have a version of vi that saves everything that is piped in a special file.

Or pgp may be modified to do the same.  

Or if you compile pgp yourself every time, the C standard input routines
may be modified to do the logging. 

You get the picture. There is no security on a multiuser system.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 26 Nov 92 08:04:46 PST
To: tony@morgan.demon.co.uk
Subject: Why electronic banks should be Redundant & Distributed
In-Reply-To: <782@morgan.demon.co.uk>
Message-ID: <9211261604.AA26880@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> UK.  I think a more real problem with anonymous banking, is not 
> one of 'trust' in the 'banker' but in his net access. What do you 
> do when your banker, for whatever reason, becomes unreachable?


The best banker deamon would run multiple copies on widely separated hosts/
networks, and keep each other up to date on accounts/balances.

They would be logically one entity, by sharing crypto keys.  

So if one is cut off from the net, or even destroyed, you just send your
messages to one of the others.

When it comes back up, the others update it with current info.

Somewhat similar (not exactly, since they do not communicate to each other)
existing system is archie.  Imagine that your life or work depended on
constant access to archie.  When there was only one archie@quiche.mcgill.ca
you could have said "What do you do when the archie, for whatever reason,
becomes unreachable?".  Now that there are many archies, the simple answer
is use one of:

	archie.sura.net (USA, Mexico, etc)
	archie.mcgill.ca (Canada)
	archie.funet.fi (Finland/Mainland Europe)
	archie.au (Australia/New Zealand)
	archie.doc.ic.ac.uk (Great Britain/Ireland)

How likely do you think ALL of these widely separated entities could be
simultaneously destroyed/disconnected?


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Wed, 25 Nov 92 16:23:55 PST
To: cypherpunks@toad.com
Subject: Re: Electronic Banking
Message-ID: <9211260023.AA11537@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


>(A minor note: I ended up doing the Xeroxing for free, which hasn't
>yet been declared illegal...though I presume you'll all carefully note
>this on your tax returns, as such "barter exchanges" are reportable
>income. In theory, which shows how hopeless tax collection is
>becoming, all of our "mutual consulting" on this list, and on the Net
>in general, is _taxable income_--just as if we were plumbers and carpenters
>getting together to work on each other's houses. A crazy system.)

So *thats* why nnacct is there :)... Does the tax office get an email from 
each news admin every fiscal year? :) So they can charge us for services 
rendered by the net?

With regard to digital cash, I have yet to read (or have forgotten the
definition) the implementation. What I preceive it as is a form of IOU's
that if someone does something for you then you send them an applicable
amount of credits. To simplify it a bank could issue credits and people
could trade in them, sending them back and forth, each digitally encrypted
and based on the amount of credits in each persons bank account. I assume 
each transaction would be validated through a bank to ensure the credit is
unique and the right value?

E.g:

  Customer gets suppliers account number from the supplier encrypted with
  the banks public key.  They send it and the amount of cash to transfer to
  the bank all encrypted with the public key of the bank. 

  The bank decrypts, gets the amount and decrypts the destination account.
  It then sends a message to the supplier saying that amount has been
  deposited in their account and the transaction between the customer and
  supplier can be completed. Otherwise it tells the supplier (and customer)
  there is a problem with insufficient funds or incorrect data.

  The cash may be held in ether until both parties confirm the transaction
  has been completed. If the commodity is electronic data the supplier may
  send to the bank a transaction private key encrypted with the customers
  public key so that the customer cant cheat the supplier as he has to ask
  the bank for the information to access his/her data which has been encrypted
  with the other half of the transaction keypair. That way the bank knows the
  transaction has been completed and it finishes the transfer of funds and
  sends the transaction private key to the customer.

  Each commodity, especially if it was physical might be serialized so there
  could be proof that the customer purchased that item with that SN. If the
  merchant was a crook the audit trail would catch him... the customer wouldnt
  be able to cheat as the merchant wouldnt have to release the goods (as is
  the situation now in Real Life (tm)) until the funds were paid.

  Issues of Big Brother spying on your transactions apply here but I guess
  one could always use a psuedonym for the electronic commodities and a
  postal box paid for with digital anonymous cash for the physical stuff..
  (assuming it was mail order... you wont have to give a name for store
   buying, just a bank public key and your encrypted account number.)

  Someone might even want to set up a physical forwarding company which 
  merely acts as a buffer for people to increase their privacy. Paid for 
  anonymously and digitally. I havent heard of any companies specialising in
  this type of service to date.

This make any sense? Has it been said before?
Mark
mark@coombs.anu.edu.au




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 26 Nov 92 11:44:30 PST
To: cypherpunks@toad.com
Subject: Cypherpunks List (fwd)
Message-ID: <9211261940.AA15763@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks,

Happy Thanksgiving!

I sent the following message to the "Extropians" list, a list centered
around discussions of politics, technology, the future, "uploading,"
transhumanism, and the like. (As with our list, they can be subscribed
to with the "-request" form.

Several requests for more information about our list prompted me to
write this summary piece. Inasmuch as our existence has been
publicized in Mondo, on alt.hackers, and in various references in
messages, I felt it appropriate to tell them a few things about what
the list is about. Our address is at the very end of the article, so
there's a minor obstacle for truly casual readers to overcome.

I'm forwarding it to you folks because we've had a lot of new
subscribers ourselves, and they may like to hear some of this stuff.

I apologize to those who are getting this twice.

-Tim May

Forwarded message:
To: Extropians@gnu.ai.mit.edu
From: tcmay@netcom.com (Timothy C. May)
Subject: Cypherpunks List
Date: Thu, 26 Nov 92 10:51:01 PST

The Cypherpunks List -- A Thanksgiving Message

I guess it's time to say a few words about the "Cypherpunks" list,
which I've referred to several times in the last few months. Eric
Hughes, the list administrator and initial organizer of our first
meeting, has also mentioned the group in several places, and the
latest "Mondo 2000" actually gives the address, so the information's
pretty much out by now.

We've avoided the "cattle call" form of invitation, where public
announcements are made and subscribers flood in. But we also haven't
gone to the other extreme of requiring some puzzle to be solved (as
with posting to "alt.hackers," which usually requires some hacking of
the posting software to "get in.") Cracking a cypher is not a
requirement, though some probably think it should be.

A few points:

* The name "Cypherpunks" started out as a pun by Jude Milhon, an
editor at "Mondo 2000," when she said "You guys are just a bunch of
cypherpunks!" We initially debated calling our informal group
something more staid like "The Cryptography Research Society," partly to
protect ourselves by emphasizing the "research" aspects, but the joke
name stuck. So, like it or not, it's "Cypherpunks." It turns off some,
turns on others. C'est la vie. 

* Note that we have very little to do with the Gibsonesque vision of
punked-out outlaws and virtual reality escapades, though in fact some
of our members are active in Bay Area start-up companies doing VR. I
would say Vernor Vinge's "True Names" is more descriptive of what
we're doing.

* About a hundred or so folks are on the list, including some
journalists (gulp!), and even some "*.mil" sites (!!). But since what
we're doing is strictly "research," we are of course safe.

* The focus is on cryptology, anonymous remailers, hardware support,
PGP, digital cash, "dining cryptographers" nets, and so on. Too much
to recapitulate here.

* By focussing on "research" into these areas, we feel we are safe
against attack by government agencies. Time will tell. These issues of
security, privacy, remailers, digital pseudonyms, etc., are hot topics
in the crypto community, and all we are really doing is applying these
ideas and doing experiments, the better to learn. (Some of the work on
"webs" of trust in PGP systems, on issues with anonymous remailers,
and on the development of "digital reputations" lies in uncharted
territory, that is, we're doing true research.)

* Several Extropians are active on the list, as you may have gathered
from cross-posts and comments.

* Because many of the early members live in the Bay Area (Northern
California, Silicon Valley), we've had three physical meetings so far.
John Gilmore, a founder of Cygnus Support, has graciously offered his
facilities for our meetings, which typically happen on Saturday
afternoons. The schedule gets posted on the list, of course.

* Some exciting progress has already been made. Eric Hughes and Hal
Finney have implemented a PERL-scripted remailer which provides
anonymous forwarding (though the security is only "manual"), and 2-way
remailers with digital pseudonyms seem imminent. Integrating PGP into
mailers remains a problem, as those of you who use PGP already know,
and several of our members are working with the PGP and MacPGP teams.

* "Crypto dongles" to attach to RS-232 ports are being pursued by
Yanek Martinson (an Extropian as well), George Gleason, John Draper
("Cap'n Crunch"), and others. Lots of enthusiastic debate.

* FIDONet users are also involved, including Tom Jennings, the founder
of FIDONet, in 1984. This brings an exciting new flavor for most
Internetters. 

* Like the Extropians list, the Cypherpunks list is relatively free
from flames and personal attacks. We all realize we're interested in
roughly the same goal, even though some are Libertarians (naturally)
while others are Socialist, Marxists, and Act Up! activists.
(Interestingly, we've never had any real flames on politics. We almost
never argue political views. This may of course be alien to readers of
the Extropians list! :-} )

* So why isn't the list sent out in encrypted form? A little thought
will reveal the uselessness of encrypting a widely distributed list
that's essentially open to anyone who sends in a request! Still, there
is some talk of encrypting in the future, partly to weed out the
casual readers (for whatever reason) and partly to just get the volume
of encrypted messages up.

If you've read this far, and are really interested in joining the
list, send a request to "cypherpunks-request@toad.com". This is
standard list procedure, of course. But please don't then complain
about the list volume!


--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: jdugger@reed.edu (Jay Dugger)
Date: Thu, 26 Nov 92 13:06:13 PST
To: cypherpunks@toad.com
Subject: Subscription
Message-ID: <m0muqPH-000FNpC@bagpipe.reed.edu>
MIME-Version: 1.0
Content-Type: text/plain


Sorry about the bandwidth waste, but please subscribe me.

------------------------
Jay Dugger
jdugger@reed.edu
------------------------
PGP Public Key available




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu
Date: Thu, 26 Nov 92 13:40:36 PST
To: Richard Childers <rchilder@us.oracle.com>
Subject: Re: chip verification ( Was: Tollhouse Cookies :-)
In-Reply-To: <9211260206.AA08221@rchilder.us.oracle.com>
Message-ID: <9211262140.AA12038@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> It seems to me that an ostensibly digital device with a fixed number
> of pins could be regarded as a finite state system, and systematically
> analyzed accordingly, IE, traverse the set of possible combinations of
> pins and signal levels and verify that it behaves in accord with pub-
> -lically available specifications.

This is not useful, because devices can have internal state.  For example, 
a device could do the same thing in response to an input for 1000 times,
and then do something different when a counter reaches 1001.

I've been employed writing test vectors for chips.  It *is* possible
to write a set of tests that will verify that a piece of hardware
matches its design (which, BTW, is software, stored on a disk in a
database).  Every chip vendor does this on every chip they make, to
detect manufacturing defects.  These tests will not detect hardware
that has been deliberately modified to pass the tests, but to do
something different in actual operation.  This is an obvious risk when
the tests are necessarily publicly available.

Of course, if a particular form of modification is suspected, people
can write new tests that look for it.  But it becomes like the virus
protection game:  looking for the signatures of known viruses doesn't
protect you from unknown ones.  There's no proven way to detect all
modifications.  

	John Gilmore

PS: See also Ken Thompson's paper, "reflections on trusting trust",
which was published as an ACM Turing Award lecture among other places.
Your CAD software could have been modified so that it inserts a mod
into your chip that doesn't appear in the chip's source code.  The
compiler used to build the CAD software could've been modified to
insert the above mod into your CAD software binaries as they are
compiled.  A compiler binary used to build the *compiler* sources into
binaries could have been modified to insert the compiler mod described
above.  Even if you have full sources, you can't trust the system --
you have to trust the people who bootstrapped it, and all the people
who wrote the tools *they* used.  "Proving" anything becomes very slippery
here.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 26 Nov 92 11:57:16 PST
To: nobody@alumni.cco.caltech.edu
Subject: Re: your mail
In-Reply-To: <9211260713.AA01656@alumni.cco.caltech.edu>
Message-ID: <9211261956.AA02380@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> If you want to do this, it is a simple matter of building a large
> enough cooperative group.
> 
> How big?  Well bigger than the Hells Angels, Maybe a thousand
> people.  I don't know.  Depends on how rough it gets.
 
Right now the list has 168 individual subscribers.
Plus, there are 6 gateways to local redistribution lists.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Thu, 26 Nov 92 15:08:58 PST
To: rchilder@us.oracle.com
Subject: Re: chip verification ( Was: Tollhouse Cookies :-)
Message-ID: <199211262305.AA20384@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


John Gilmore points out that in hardware, "proving anything becomes very
slippery..."  Seems to me that we can establish degrees of confidence, in
much the same way as pertains to social sciences research: probabilities
that a given result is accurate.  So for instance, we could say that a
device made with parts purchased randomly for cash over the counter at a
number of different suppliers, might have a lower probability of compromise
than one made with parts mail-ordered from the same large supplier to the
producer's workshop every time.  Over time it may be possible to quantify
the measure of confidence.  

-gg.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Thu, 26 Nov 92 16:04:18 PST
To: crunch@netcom.com
Subject: Mac PGP report and Rander progress
In-Reply-To: <9211260933.AA04417@netcom2.netcom.com>
Message-ID: <9211270003.AA20577@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


Has anyone given any thought to generating random numbers by counting
particle emissions from a radioactive source?  This might be more
reliably random than using purely electronic means.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Thu, 26 Nov 92 23:06:08 PST
To: cypherpunks@toad.com
Subject: The NSA Backs Down!!
Message-ID: <9211270705.AA06258@servo>
MIME-Version: 1.0
Content-Type: text/plain


r a AM-DeclassifiedCodes     11-26 0287
^AM-Declassified Codes,0266<
^Government Reverses Itself, Declassifies Studies On Secret Codes<
	   SAN FRANCISCO (AP) _ The National Security Agency has reversed
itself and declassified two cryptography texts it previously had
insisted were secret even though they were available in public
libraries.
	   The announcement Wednesday came as a result of a lawsuit filed
under the Freedom of Information Act by a Silicon Valley computer
scientist who believes private companies should have more access to
secret code technology.
	   The analyst, John Gilmore, asked the spy agency to declassify
the 50-year-old studies on encryption _ the science of designing
codes.
	   The U.S. Department of Justice recently had threatened to
prosecute Gilmore under a 1950s espionage law if he distributed
copies of the texts.
	   In court papers, an NSA official said disclosure of the
information could seriously damage national security. The agency is
in charge of protecting U.S. codes and cracking foreign ones.
	   Gilmore is a board member of the Electronic Frontier Foundation
of Cambridge, Mass.
	   The organization believes now-secret encryption technology is
necessary for private companies to make modern computer and
telephone systems secure from tampering.
	   ``Why shouldn't an American citizen be able to go to the library
and teach himself about encryption?'' asked Michael Godwin, a staff
counsel at the foundation.
	   Gilmore said he found copies of the once-declassified studies,
made secret again by the Reagan administration, in public
libraries. They presently are used as texts in military classes.
	   He said he plans to distribute 20 or 30 copies to other
libraries. The studies are about 1,000 pages long.
	   AP-DS-11-26-92 1837EST<




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Fri, 27 Nov 92 00:30:10 PST
To: cypherpunks@toad.com
Subject: (fwd) 8052-Based Crypto Engine
Message-ID: <9211270825.AA03153@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


I just found this is sci.crypt. It may be useful for the "crypto
dongle" folks.

--Tim May


Newsgroups: sci.crypt,comp.arch
Subject: 8052-Based Crypto Engine
From: mmm@cup.portal.com (Mark Robert Thorson)
Date: 27 Nov 92 06:50:33 GMT

Here is the text from a press release which landed on my desk
yesterday:

A new microcontroller from Philips Semiconductors-Signetics designed
for use in smart-card applications is the first to incorporate an on-chip
arithmetic unit optimized to calculate public-key cryptography
algorithms widely used in commercial transactions.

The 83C852 CMOS microcontroller can be embedded in plastic smart cards
and provides 2K bytes of on-chip EEPROM for program and data storage
accessed under control of the unit's CPU.  "The new microcontroller removes
the barrier to smart-card use in applications where data security is a
concern," said Thomas Brenner, product manager.

"There is strong interest in using smart cards, for example, in medical
insurance or remote banking transactions.  But in such applications a
high level of data security is indispensable," he said.  "Likewise
the need for secure access codes is a primary consideration for
customer-card use in the Pay TV and cellular phone markets."

The on-chip arithmetic unit running in parallel with the CPU can complete
a 512-byte calculation in less than 1.5 seconds versus more than a
minute to do the calculation in software.  This high-speed performance
makes it feasible to use highly secure and complex public-key
cryptography algorithms in everyday transactions.

Asymmetric, public-key cryptography uses one key to encrypt and another
to decrypt so that only one of the keys need be kept secret.  The other
can be freely distributed.  The method is thus highly applicable to
commercial transactions.

The 83C852 microcontroller is based on the industry-standard 8-bit
80C51 processor core and uses the same instruction set.  The circuit
incorporates 6 Kbytes of ROM and 256 bytes of RAM in addition to the
2 Kbytes of EEPROM.

The EEPROM provides automatic hardware error correction for single-bit
errors in any of the stored data bytes.  After customer software is loaded,
electronic fuses in the array can be blown to limit access to processor
fetch commands.  The address bus is mixed to provide further protection
against fraudulent access and optical scanning, and a low-frequency
detection circuit can guard against external tampering.

The new processor operates from a single 5-volt supply at clock
frequencies up to 6 MHz (1 microsecond instruction cycle).  All voltages
required during programming or erasure of the EEPROM are generated on chip.
Nonvolatile data retention is for ten years and the circuit offers an
infinite number of read cycles.  The microcontroller includes a power-on/off
reset circuit, and idle and power-down modes.

The microcontrollers can be ordered as a wafer, die on foil or in SO-28
small-outline packages.  The SO package is available for smart-card
readers and can function as an embedded security module in systems such
as restricted access computers.

Wafer and die-on-foil versions of the 83C852 smart card microcontroller
are available now at a unit price of $5.10 and $5.20 respectively in
10,000 quantites.  Units in SO-28 packages will be available in
first quarter 1993 priced at $6.85 in the same quantities.

CONTACT:  Thomas Brenner (408) 991-3552

He's with Philips-Signetics.  I have no affiliation with them, so don't
contact me about this part.  If you call Tom, be sure to tell him you
heard about the chip from MARK THORSON on USENET.  If enough people
do this, maybe they'll give me a free development system.  (On the
other hand maybe they'll tell me "Please don't post any more of our
press releases on Usenet." :-)

--
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.















From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: efrem@informix.com (Efrem Lipkin)
Date: Fri, 27 Nov 92 01:57:06 PST
To: cypherpunks@toad.com
Subject: credibility & pseudonyms
Message-ID: <9211270916.AA25959@godzilla.informix.com>
MIME-Version: 1.0
Content-Type: text/plain


I have this persistent image of what a great boon all these
encrypted networks will be for undercover work. Currently when
some species of cop or spy goes undercover they take on a nearly
full time acting job. They have to work for a long time to
establish their credentials and throughout the process are usually
in significant physical danger. I vaguely remember (the details are
probably wrong) some Isreali spy got as far as the position of Minister
of Defense in Jordan before he got hung.

With digital signatures a dozen secretaries could run a hundred or more
pseudoagents, build a solid reputation for each over years.

The same approach would work for a patient con man. 

Real credibility has to be tied to a physical body. Some thing
at risk.

--efrem




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: cordones@IMAGE.CS.NYU.EDU (Deus Ex Machina)
Date: Thu, 26 Nov 92 23:21:34 PST
To: cypherpunks@toad.com
Subject: Re: Returned mail: User unknown
Message-ID: <9211270719.AA20772@IMAGE.CS.NYU.EDU>
MIME-Version: 1.0
Content-Type: text/plain




So..any courageous Cypherpunk that can post those papers or tell us what to look for in a library? (anonymous post, whatever).

-----------
El Zorro.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: donb@netcom.com (Don Bellenger)
Date: Fri, 27 Nov 92 08:30:05 PST
To: cypherpunks@toad.com
Subject: Cypher Bank
Message-ID: <9211271625.AA08403@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Does anyone know of a law, rule, regulation, or other restriction 
that would prohibit the establishment of a simple cypher based bank?

I can think of 3 basic areas that would have to be satisfied:

     1.  Federal law and agencies, Federal Reserve, etc..

     2.  State and local (California for me).

     3.  Internet "Appropriate Use" policy.

If the bank is operated on a not-for-profit basis  --as an 
experiment.  Then that should satisfy the appropriate use 
requirement.

I could use some comments if anyone can cite specific federal or 
California regulations.  Please respond either to me directly, 
donb@netcom.com, or to this mail list.

--------

The cypher bank would work like this: I would publish my physical 
address; and offer to accept deposits by cash, check, or what have
you.  With the deposit, write on it your PGP handle.  Email me your 
public key corresponding to the handle on the deposit.

I will maintain a public list showing handles vs. Amount received,
in collection, and in escrow.(Set Subject = "BANK" to get the list)

Funds will be paid out based on instructions encyphered with your 
private key.

Comments would be appreciated.

Don Bellenger
donb@netcom.com






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tony@morgan.demon.co.uk (Tony Kidson)
Date: Fri, 27 Nov 92 08:56:24 PST
To: cypherpunks@toad.com
Subject: Re: Mac PGP report and Rander progress
Message-ID: <842@morgan.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


In message <9211270003.AA20577@napa.TELEBIT.COM> you write:
> Has anyone given any thought to generating random numbers by counting
> particle emissions from a radioactive source?  This might be more
> reliably random than using purely electronic means.
>
I don't think that for any given length of random bit string, 
you'd be practically happy carrying around a suitable source. 
Thermal noise, which is what you get from a diode, is just as 
good a random source as radioactive decay.

Tony
------------------+-------------------------------+--------------------------+
| Tony Kidson     |`morgan' is an 8MB  486/33 Cat-| Voice +44 81 466 5127    | 
| Morgan Towers,  |Warmer with a 670 MB Hard Disk.| E-Mail                   |      
| Morgan Road,    |It  resides at Morgan Towers in| tony@morgan.demon.co.uk  |
| Bromley,        |Beautiful  Down Town  Bromley. | tny@cix.compulink.co.uk  |
| England BR1 3QE |            -=<*>=-            | 100024.301@compuserve.com|
+=================+===============================+==========================+




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: donb@netcom.com (Don Bellenger)
Date: Fri, 27 Nov 92 08:55:12 PST
To: cypherpunks@toad.com
Subject: ping
Message-ID: <9211271651.AA09053@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


This is a test.  I am seeing mail rejected due
to mail spool full @ newschool.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: donb@netcom.com (Don Bellenger)
Date: Fri, 27 Nov 92 09:20:12 PST
To: cypherpunks@toad.com
Subject: List is partially broken
Message-ID: <9211271715.AA20966@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


The message below was received in response to a ping sent
to this list.  However I know that it got some distribution
because Yanek answered it.

donb@netcom.com



Forwarded message:
> From Mailer-Daemon Fri Nov 27 09:03:27 1992
> Message-Id: <MAILQUEUE-102.921127120540.672@newschool.edu>
> From: Postmaster@newschool.edu
> To: donb@netcom.com
> Subject: Rejected Mail
> Date:    Fri Nov 27 12:05:03 1992
> 
> 
> Unable to deliver message because: 
> 
>       @ : Insufficient Disk Space
> 
> Returned Text follows
> -------------------
> Received: From relay2.UU.NET by newschool.edu
>           via Charon 3.4 with SMTP id 102.921127120528.384;
>           27 Nov 92 12:04:51 +0500
> Received: from toad.com by relay2.UU.NET with SMTP 
> 	(5.61/UUNET-internet-primary) id AA03427; Fri, 27 Nov 92 11:56:15 -0500
> Received: from netcom2.netcom.com ([192.100.81.108]) by toad.com id AA01076; Fri, 27 Nov 92 08:55:12 PST
> Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom)
> 	id AA09053; Fri, 27 Nov 92 08:51:00 -0800
> Date: Fri, 27 Nov 92 08:51:00 -0800
> From: donb@netcom.com (Don Bellenger)
> Message-Id: <9211271651.AA09053@netcom2.netcom.com>
> To: cypherpunks@toad.com
> Subject: ping
> 
> This is a test.  I am seeing mail rejected due
> to mail spool full @ newschool.
> 
> 


-- 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hughes (Eric Hughes)
Date: Fri, 27 Nov 92 10:48:33 PST
To: cypherpunks
Subject: Welcome message for cypherpunks-announce
Message-ID: <9211271848.AA03598@toad.com>
MIME-Version: 1.0
Content-Type: text/plain



We've created a secondary list, cypherpunks-announce@toad.com.

If you want to keep in touch, but don't want the volume of mail the
full list produces, get yourself switched over.

And remember not to post such requests to the whole list.  Thanks.

The welcome message follows.

Eric

-----------------------------------------------------------------------------
Date: Fri, 27 Nov 92 10:44:31 PST
From: hughes@toad.com (Eric Hughes)
To: cypherpunks-announce
Subject: Welcome


Welcome to the cypherpunks-announce list.

This is a low-volume list for announcements, news, and meeting
schedules.  It is not a digest.  It is moderated by Eric Hughes, also
the maintainer of the full list.

Each of you has at some point been on the full list and asked to be
dropped for mail volume.  If you really don't want to be even on the
announce list, send mail to 

	cypherpunks-announce-request@toad.com

and ask to be removed from the announce list.

Eric





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: daver@tfs.COM (Dave Robison)
Date: Fri, 27 Nov 92 13:15:47 PST
To: cypherpunks@toad.com
Subject: ...
Message-ID: <9211271916.AA18212@ts2.TFS.COM>
MIME-Version: 1.0
Content-Type: text/plain


please remove me from this list. as interesting and important as i think
the discussions are, i cannot keep up with the volume of mail.

thanks.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: cordones@IMAGE.CS.NYU.EDU (Deus Ex Machina)
Date: Fri, 27 Nov 92 09:01:18 PST
To: cypherpunks@toad.com
Subject: Re: ping
Message-ID: <9211271659.AA21574@IMAGE.CS.NYU.EDU>
MIME-Version: 1.0
Content-Type: text/plain



Me too. In fact, I am insecure my message ever got through because no one has said anything about it. It was regarding "The NSA backsdown". I was asking how could point me to thse so called "secret" documents that are available at some libraries. Did that get through Boys?


Thanks




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Fri, 27 Nov 92 10:22:36 PST
To: donb@netcom.com (Don Bellenger)
Subject: Re: list broken (NOT!)
In-Reply-To: <9211271715.AA20966@netcom.netcom.com>
Message-ID: <9211271734.AA24635@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> The message below was received in response to a ping sent

> > From: Postmaster@newschool.edu
> > To: donb@netcom.com
> > Subject: Rejected Mail
> > 
> > Unable to deliver message because:  @ : Insufficient Disk Space

This does not mean that the list itself is broken, only one (or a few)
recipients have problems.  You would have a cause to worry if you received
a rejection message from toad.com.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Fri, 27 Nov 92 10:25:55 PST
To: donb@netcom.com (Don Bellenger)
Subject: comments on Don's "Cypher Bank"
In-Reply-To: <9211271625.AA08403@netcom2.netcom.com>
Message-ID: <9211271825.AA25349@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> address; and offer to accept deposits by cash, check, or what have
> you.  With the deposit, write on it your PGP handle.  Email me your 
> public key corresponding to the handle on the deposit.

A better way would be to mail the public key itself, or a short 
hash of it along with your payment.  That is all the information that
would be required.  A "handle" would be completely optional. 
If only the hash value is mailed, then the full key can be e-mailed
or anonymously posted to a newsgroup that you montitor.  If the full key
is mailed, you should invest in a scanner and some simple OCR software.

This way, someone may print out the public key and mail it to you.

> I will maintain a public list showing handles vs. Amount received,
> in collection, and in escrow.(Set Subject = "BANK" to get the list)

You should not disclose someone's balance to anyone else, and certainly
no to the public.  Someone requesting their balance should send the
request by any communications channel (anonymous mail, newsgroup, anything)
and sign it with the private key corresponding to the public key used
when making the deposit.  Then you should encrypt your reply (the account
balance & any other info) using the public key, and send it back through
any channel.

> Funds will be paid out based on instructions encyphered with your 
> private key.

I would make it: funds will be transferred based on instructions _signed_
with the private key corresponding to the public key used for deposit.

P.S. this would be equivalent to digital checking accounts.  Do not confuse
this scheme with the much more interesting Digital Cash ideas.

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: donb@netcom.com (Don Bellenger)
Date: Fri, 27 Nov 92 13:33:24 PST
To: cypherpunks@toad.com
Subject: More cypher bank
Message-ID: <9211272129.AA26164@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


No one else's account would be disclosed except to the owner.
Handle, hash, or the full key itself is all the same.
The point is that some shortened identifer is needed.
This is not a technical matter, the customer can cook up anything
he wants,  There is no relation to the mechanics of PGP,
I don't want to bother scanning in and verifying long
strings of codes, and I need some short I.D.  so the owner can identify
his balance for verification (checking balances). 
There are obviously plenty of fancy variations
on this, and I would be happy to set up whatever any body wants.
Maybe the easiest way is to setup mail addresses for each
depositor of the form:  handle_of_depositor@digibank.com.  So send signed
email to that address, and I will respond with your  
balance.  A couple of other addressees would be used for overall bank
status report, and current operating rules.

The digital cash account is represented by the escrow balance.  If Sam
wants me to take his collected funds and turn them into digi-cash, I can
sign a voucher that I have segregated X amount of Sam's money into an
escrow account pending receipt of the digi-cash voucher and instructions
to move the escrow amount elsewhere.  This is all that any bank is going
to do.

Basically, this looks like a very good thing to do.  If handled
properly and within the banking regulations, it could be a great
advance.  Does anybody here remember pre-ATM days?  Standing in
line at the bank to get cash?  In 3rd world countries they don't 
even have checking.  This means you have to walk around every month
and pay your bills in cash. 

I haven't been in a bank in years since the ATMs came in.
And this is at another, much higher level of abstraction. 



> 
> > address; and offer to accept deposits by cash, check, or what have
> > you.  With the deposit, write on it your PGP handle.  Email me your 
> > public key corresponding to the handle on the deposit.
> 
> A better way would be to mail the public key itself, or a short 
> hash of it along with your payment.  That is all the information that
> would be required.  A "handle" would be completely optional. 
> If only the hash value is mailed, then the full key can be e-mailed
> or anonymously posted to a newsgroup that you montitor.  If the full key
> is mailed, you should invest in a scanner and some simple OCR software.
> 
> This way, someone may print out the public key and mail it to you.
> 
> > I will maintain a public list showing handles vs. Amount received,
> > in collection, and in escrow.(Set Subject = "BANK" to get the list)
> 
> You should not disclose someone's balance to anyone else, and certainly
> no to the public.  Someone requesting their balance should send the
> request by any communications channel (anonymous mail, newsgroup, anything)
> and sign it with the private key corresponding to the public key used
> when making the deposit.  Then you should encrypt your reply (the account
> balance & any other info) using the public key, and send it back through
> any channel.
> 
> > Funds will be paid out based on instructions encyphered with your 
> > private key.
> 
> I would make it: funds will be transferred based on instructions _signed_
> with the private key corresponding to the public key used for deposit.
> 
> P.S. this would be equivalent to digital checking accounts.  Do not confuse
> this scheme with the much more interesting Digital Cash ideas.
> 
> --
> Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
> this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
> Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
>       (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819
> 
> 


-- 





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Fri, 27 Nov 92 10:46:45 PST
To: cordones@IMAGE.CS.NYU.EDU (Deus Ex Machina)
Subject: Re: ping..mailing list integrity..
In-Reply-To: <9211271659.AA21574@IMAGE.CS.NYU.EDU>
Message-ID: <9211271846.AA25768@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> Me too. In fact, I am insecure my message ever got through because no one
> has said anything about it. It was regarding "The NSA backsdown". I was
> asking how could point me to thse so called "secret" documents that are

I have not received it.  It may have just been a local network problem
on your side.  But it may also have been covert action (if you are 
paranoid enough to believe it). 

I have an idea how we could make it possible for eveyone to be SURE that
their message to the list actually went out; and also they could be certain
that they have not missed any list messages.  

This is very important for people with unreliable or untrusted e-mail
connections.

The idea is:  whenever cypherpunks@toad.com receives a message, it would
append the From:, Date:, and Subject: headers to a file, thus creating
an index of messages passing through the list.  At the end of each day,
the file would be mailed out to the list.

So if you posted a message, you could check in the evening if it got
out or not.  If you are not sure if you are receiving all the messages,
you could maintain a simlar file yourself, and at the end of day compare
your notes with what is received from the list.

This should not be difficult to set up at all.

This could be later improved in several ways.  First, the message could
be signed by the list administrator (in case you think your mailfeed
is filtering what you receive, and is also removing these items from 
the index).

These indexes could be kept for a week or so, and either only the lists, 
or maybe even any of the individual messages that may have been missed
could be requested via a mailserver.  This could work similarly to the
CRYOMSG: facility of the Cryonix mailing list.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Fri, 27 Nov 92 15:05:14 PST
To: cypherpunks@toad.com
Subject: Re: How far is to far?
Message-ID: <9211272304.AA09837@servo>
MIME-Version: 1.0
Content-Type: text/plain


I must concur with George Gleason's remarks about "sneaking around in
the shadows of legality". I find myself getting a little uncomfortable
with some of the more anarchistic ideas expounded in this and similar
groups.

My interest in cryptography is very simple. I'm not interested in
overthrowing the government by force. Although I find "digital cash"
to be an interesting concept worthy of pursuit at least as an academic
exercise, I'm not trying to evade income taxes, establish an
underground economy or conceal criminal activity.  And although I do
believe that drugs, gambling, prostitution and other vices ought to be
legalized on both practical and philosphical grounds, I am not
particularly interested in using cryptography to protect the lowlifes
who inhabit these professions.

I am *very* interested, however, in cryptography's enormous potential
to protect individual privacy. With widely available strong
cryptography, the average individual will finally have the technical
means to draw a tight circle around the private aspects of his or her
life. The individual need let no one, especially the government, enter
without his or her permission.

Until now, we have had to depend entirely on the goodwill of
government to respect and obey those provisions of the Bill of Rights
that deal with privacy. Often this "good will" has been sadly lacking.
But now we can finally put some real teeth into the guarantees of the
First, Fourth and Fifth Amendments.  If you want to plot political
strategy for an upcoming election, or if you want to talk to your
attorney about some legal action, or even if you just want to discuss
your sex life with your spouse or SO, cryptography can guarantee you
an unprecedented degree of privacy. Just as good fences make good
neighbors, we may well find that in the hands of the people, good
cryptography will make for good government.

That's why I find cryptography so interesting, and that's how we
should sell it to the public.

Phil





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Fri, 27 Nov 92 15:53:20 PST
To: cypherpunks@toad.com
Subject: More comments on dongles
Message-ID: <9211272352.AA09880@servo>
MIME-Version: 1.0
Content-Type: text/plain


George Gleason says

"I believe that carrying out the entire crypto operation in the dongle is
preferable to having it only do the secret key RSA processing"

and argues for this position mainly on the basis of host compatibility
issues.

I still disagree. Even if all the crypto operations were done in the
dongle, it wouldn't be a "turnkey" device that could operate totally
automatically.  You'd still need a way for your host computer to turn
it off and on, to select a public key for encryption or signature
verification, to load new public keys, etc. I.e., you'd have to run
special driver software on the host anyway. So why not limit the
dongle to the specific purpose for which it was designed (protecting
your RSA secret key) and do the less sensitive operations where memory
and cycles are far more plentiful, i.e., on the host?

Limiting the dongle's function to RSA secret key operations also
minimizes the dongle's communication requirements.  The only data
you'd have to send to it in normal operation would be short blocks to
be run through your RSA secret key operation, a heavily compute-bound
process. If I want to decrypt a file, I'd send the dongle the IDEA (or
DES) key that had been encrypted with my public key. Once the dongle
responds with the decrypted IDEA key, I can perform the actual IDEA
decryption on my host computer with no further dongle interaction.
Regardless of the file size, this would go at host CPU and/or disk
speed, not the speed of the port that's talking to the dongle.

Similarly for signing -- the MD-5 hashing of the file would proceed at
near disk speed (since MD-5 is so fast) and only the resulting hash
code would have to be passed to the dongle for the RSA secret key
step.

A palmtop DOS machine like the HP-95 or Atari Portfolio would make a
good platform for a prototype dongle.  Most have serial ports
(standard or optional), and you could just plug them into a spare
serial port on a PC (again, speed is not critical). The palmtop's
keypad would be used to control the dongle, e.g., by accepting a pass
phrase to decrypt the stored copy of your RSA secret key, so you
wouldn't have to type it into a possibly compromised PC. And they're
small enough to carry around with you, thus making it harder for
somebody to hack.

The only drawback I can see to all of this is that palmtops are not
exactly speed demons, and RSA secret key operations are pretty slow to
being with (much slower than the public key operations, which are less
sensitive). But secret key operations are the heart of RSA, so you
don't have much choice if you want real security.

Since it is a sensitive step, RSA key generation could also be done on
the palmtop (although it would probably take hours) or it could be
done on an external, trusted PC and loaded into the palmtop. If your
main reason for using the dongle is to limit the trust you have to
place in a borrowed PC (as opposed to protecting against your own home
PC being hacked), this may be a reasonable thing to do.

Another idea just occurred to me. If you have a trusted machine (e.g.
your home PC) available to you over the net, you could use it as a
"remote dongle". You'd send it data to be run through the RSA secret
key operation and it would return it. Obviously, to be secure the
network exchanges would have to be encrypted in both directions,
otherwise anybody could either pick up the "remote dongle's" responses
or worse, send it data of his own choosing. A simple symmetric cipher
(IDEA, DES) would be adequate here since you control both ends of the
link.

The main drawback of this approach (other than the need for network
connectivity) is the physical vulnerability of your unattended home
PC.

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: donb@netcom.com (Don Bellenger)
Date: Fri, 27 Nov 92 17:11:14 PST
To: cypherpunks@toad.com
Subject: Re: Random numbers
Message-ID: <9211280107.AA08614@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


> > 
> >     It has lately been discussed different ways to construct pure
> > random number generators by means of radiactive decay. I must admit
> > that this is a very good way to produce such numbers, but for a
> > number of reasons it is impractical to use such a device. (High
> > radiation levels are needed too produce a significant amount of data.)
> 
> 
> The way to make good random numbers is to take about 20 stages of flops
> and feedback 2 or three terms.  Clock the thing as fast as you can, Say
> 50 mhz, and asychronously to your main processor clock.  The shift register
> needs its own crystal.  The selection of feedback points is based on
> Linear Congruential Method of Pseudo random numbers generated by most
> machines.
> 
> The numbers generated are very, very uniform.
> 
> The way to test random number generators for randomness is to generate
> the numbers in pairs and plot them on a scatter plot.  This simple
> cross check will show up many poor generators.  Checking for uniform
> density in higher dimensions will uncover even more subtle variations
> from uniformity.  There is an enormous literature on this topic.  Obviously
> you can screw it up, but it isnt that hard to get right either.  There
> is an excellent book just out on simulations that covers  this.  If
> anyone wants the reference, I can dig it up.
> 
> Bottom line is that you don't need anything exotic.  But the 8 or simple 16
> bit methods on the small processors are no good.
> 
> Don Bellenger
> donb@netcom.com
> 
> 
> 
> > 
> 


-- 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 27 Nov 92 18:34:33 PST
To: cypherpunks@toad.com
Subject: Re:  Random numbers
Message-ID: <199211280233.AA21798@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Vanguard's posting about a friend of his in the Air Force telling him some
things about Air Force crypto devices may be of some theoretical interest,
but posting it here really gets me majorly uncomfortable.   Current military
crypto practices are probably very highly guarded secrets.  Posting that
kind of thing, even in a general way, could be very dangerous; if not to
national security then at least to ours.  

I'd like to ask we have a general agreement to not post things which may be
classified.  No point giving the govt a good excuse to stop our R&D projects
cold.  

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Fri, 27 Nov 92 18:49:41 PST
To: yanek@novavax.nova.edu
Subject: Re: More comments on dongles
Message-ID: <9211280249.AA10136@servo>
MIME-Version: 1.0
Content-Type: text/plain


>The way I envision it, the host must NOT have the ability to turn it on
>or off or do any of the other things you mentioned.  The assumption is
>that you DON't trust the host.

If you don't trust the host, then why are you running your plaintext
through it?

As I said earlier, my decision whether to trust a particular machine
depends heavily on how much I would lose if that trust were abrogated.
I might be willing to take the chance that this particular borrowed or
public PC has been hacked if the worst that can happen is that the
only slightly sensitive plaintext I'm working on at the moment is
compromised. Heck, I might even be signing or decrypting totally
public information, just to help raise the amount of encrypted traffic
on the net. In this case I might not care at all if my plaintext is
secretly recorded or sent somewhere.

But I would probably NOT be willing to trust the same PC with my
secret key, because it would compromise EVERYTHING I have ever
protected (or will protect) with that secret key. Including THE most
sensitive stuff I might have, the plaintext to which I might entrust
only to a RAM disk on my own home PC. Do you understand the
distinction here?

>So if the host does not even need to know the dongle exists, it is
>automatically independent of what type of computer, operating system,
>communications program or terminal you are using.

I seriously doubt this will be practical, even with constant
interaction with the dongle's keyboard. Most palmtop keyboards are a
real pain to use, so I would definitely prefer to limit my use of it
to truly sensitive things, like typing in my pass phrase to decrypt my
RSA secret key, or perhaps hitting a key to re-enable the device after
every N secret key operation requests from the host, or to restart a
timer that would otherwise exit the program and clear RAM after a
timeout in the event the device is lost or stolen.

>Again, you are trusting the host.  What if the decryption program on 
>the host has been modified to quietly write the plaintext to a hidden 
>file.  

As I said earlier, your "fully-functional dongle" fails to prevent
this attack. If it sits on a serial port between your possibly hacked PC
and the outside world, then it clearly must pass decrypted plaintext
to the PC where it could still be quietly written to disk.

>Once the host decrypts the file (at a high speed, as you say), you want
>to view the file, right?  That means the plaintext is transmitted from
>the host to you.  Anywhere in the link (which could be a simple RS-232
>connection, or a chain of network links, modem connections, etc.,
>someone may be watching.  With my design, the decryption takes place at
>the very last step, just before showing up on your screen.

Eh? The model I have is a local PC, possibly hacked, with a serial
port connected to my personal dongle sitting right beside it.
Obviously it would not do to have an insecure link between the PC and
the dongle (unless you had encryption on that link, as I suggested in
the case of using a remote machine in place of the dongle.) It should
be fairly hard to inject your own traffic on my 1-foot RS-232 link,
especially if I provide my own cable.

>I have thought of that too.  I would need one with two serial ports
>though.  If you know of a good, cheap (can something have these two
>properties simultaneously? :-) notebook computer with (option of?) two
>serial ports, please let me know.

The "basic dongle" would only need one RS-232 port, and it would not
have to be fast. This is a definite advantage.

>That is just one of the reasons.  The others are convenience, lack of
>trust in the host or the network, use of a terminal (which can't run any
				   ^^^^^^^^^^^^^^^^^
This is the one valid reason I can see for your approach. But dumb terminals
are getting pretty rare these days, at least in the places I hang out.

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Date: Fri, 27 Nov 92 19:58:40 PST
To: cypherpunks@toad.com
Subject: re: Re: How far is to far?
Message-ID: <3920.2B16E302@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



 U> From: karn@qualcomm.com (Phil Karn)

 U> I must concur with George Gleason's remarks about 
 U> "sneaking around in the shadows of legality". I find 
 U> myself getting a little uncomfortable with some of the 
 U> more anarchistic ideas expounded in this and similar 
 U> groups. 

I agree, even though I'm interested in uses of encryption other than
privacy, implementation of privacy systems is a baseline to a lot of
it, and the other stuff drags us off topic...

--- ReadMail
 * Origin: tomj@fidosw.fidonet.org / World Power Systems (1:125/111)
--  
Tom Jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings
INTERNET - Tom.Jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu (John Gilmore)
Date: Fri, 27 Nov 92 20:15:40 PST
To: cypherpunks@toad.com
Subject: Keys & Signatures
Message-ID: <9211280415.AA12997@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Here is the collection of keys and signatures from the last meeting.
Feed this file into pgp to add them to your key ring.

Please remember that posting "your" public key is not sufficient when
you want people to believe that the key corresponds to a physical person (you).
It's fine for communicating with people who you have't met or don't care
to meet.  But the way we can tell that the key matches the physical person
who we met, is to have it signed by someone we trust.  The signature
indicates that "I certify that this key really does belong to the physical
person identified in the name field".  Don't sign someone's key unless
you are sure you can make that statement (like, they're standing in the
same room with you and they verify that they key ID matches their real key).
Don't sign a key that you received by email or over a modem; it might
be from someone impersonating your friend (when they left their keyboard
unattended for a few minutes).

PGP works on the model that you specify, for each person on your key
ring, how much you trust them to introduce you to other people.  For
example, I trust Tom Jennings "most of the time", and I got Tom's key
from him personally.  So I know that if Tom's signature appears on
someone's key, it probably really is that person.  I've instructed PGP
to know this, too.  I also trust Phil Karn as an introducer, and got
his key from him personally.  PGP knows that if both Phil and Tom have
signed someone's key, that I can believe it *really* is that person.

The people you trust will be the people *you* trust; don't rely on trusting
someone else's friends.  We are trying to set up an interlocking web of
trusted friends so that even if you don't know me, you will know and trust
two other people who know me, and can thereby know my key is good.

Making a key distribution system that works on a web of trust is
research.  It's never been done before.  We'd like to give it a good
try, among highly motivated people, to understand how it works and how
to improve it.  The alternative we're faced with (e.g. in PEM) is
hierarchical systems in which some authority figure signs your key --
with all the attendant possibilities for misuse of power.  Let's see
if a looser, more flexible system can work as well or better.

	John Gilmore

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQBNAisOwBkAAAECAMw+W4OgXIO8E42bAT+fbwoo20aP5WBiBoLeiED3kBOSYa8F
eLRU947sfn2VobobfSkg14TmPkMfDfdWhd2+DdUABRG0IkpvaG4gVC4gRHJhcGVy
IDxjcnVuY2hAbmV0Y29tLmNvbT6JAFUCBRArDvZGVANHFAAi5S0BAWVRAgCidKO5
wvC9lQbMYfUZC9zOoqYbnRZF8JGDIRdHeELef78VpXydTLG09OHC0GA4zqfFrtCp
kvCXKIEKsvDp5YmciQCVAgUQKw7yAa1SSlGFGX+1AQHObQP/dqMl0C4z0YxYjrAI
ChV84C0pvaLVAShooyRI7c+rZO8RsmOIh44Stex+6vQcw2w2Ceh+NN7g7qGclCNf
m8eHz3FKSZBUV1BFcMBKpb3+/1d/iZueaf5eqA22l5BBumy7KLJpATrM+vegMVFA
MSdngyy6MMW9OhAZmN76OKuOJR+JAFUCBRArDtzezT/tLvUlcRcBAZonAfwI85gt
tgoBtqZRUgVMJcXKZcERprMv8Isqcnw0oRhd/fbQBYBMJYK1cRCdfqGw+8jr4xTl
dJoHm7WjvQkLzY8smQBNAisO4xwAAAECAKkyDQst9WhzHdko62Kd78+Ga8B3tLa3
Qr6zOXskoVaSYo9tLG2qo7bKs3W6SL7LgLRGaXqSC4Wyr7SLG737Hy0ABRG0IUdl
b3JnZSBHbGVhc29uIDxnZ0B3ZWxsLnNmLmNhLnVzPokAVQIFECsO5fTNP+0u9SVx
FwEBoOoB/17ngP0LwTFVGdxjbfB7BPz9kfYet/o2qkTfehc8WRvh/Xgx13ErY5kJ
FBs8Qew75HCqBzDsGxiG8g44iHOxpDeJAJUCBRArDuPErVJKUYUZf7UBAfDmA/40
zI0SEtkE87LJJk4/d3Y2lLhBAv2YWXLckS/V/6G9n/MRILJR3s3x1staVEio3rHO
bu+piG0uJm8kj2ShW1KFZrLAx5902BUM6ic+ZXDKjJ/SgCkVPr+RPc11HpqfWjpQ
GiBSTmzRGjVfzDhcmbGneNq6O2oLJRlBqdaacK8DepkATQIrDsOwAAABAgDqJjAj
dvu+tnRbDqmT02kwH9It43bqMd317SIGSnFQiU85b1RbfFYmA3fEOiA434Z/dASU
AfFSUk4YBjePiYYxAAURtDBTY290dCBDb2xsaW5zICg1MTIpIDxTY290dF9Db2xs
aW5zQGdlbm1hZ2ljLmNvbT6JAFUCBRArDvYKVANHFAAi5S0BAenEAf49x8d+g4dm
7qK3cLIPfjNngmPZqEXcQ8dD/gtPAYADx4VkuXAqhmFvg6sdfJCk9j9vUrg+ReVN
LFJN2rm/hAQEiQBVAgUQKw7fJw33VoXdvg3VAQEttAH/UnzcdPIK6SopvlPVp6gS
+pMGt8xkd4U7dI5XCtKNdlbczBKjSeHw/+OBBjZLoFqMrWUtyimwUCe3auLxRzup
GokAVQIFECsO2arNP+0u9SVxFwEBhbEB/0QkJoNqPA8CRPnkp9yYdIcB8EiTD3qY
JYKvP0fuf5gOWAyurEa6wCCxgZwFuBWA7s+lTHDJH0EkUWr/whNdZLmJAJUCBRAr
DtZIrVJKUYUZf7UBAQ3CBACPs+6OSUG2GPudoyEz2ZgCU06WhitFADFTyLL2ADyw
cznnt+u6/HBKTFjofC2CxFMoU1flYa927c8iRDEH5kwhbari3m68lWm82WQ41N7l
nYuSV2L10elmtbpdVwtBYz/qlB+ONJma0ryahoVdRyCDXsDYnk1ch7sZd3hhvKH0
7pkATQIq1hAPAAABAf4nzLRuYjfdZYmgNbDw91ZfnS6numEF9zKHQhSPMdSgyEoV
2h/I/KAyonOvPgGrpbvySXRwfvHy2ZSNMq4JDJ1TAAURtCVFcmljIEhvbGxhbmRl
ciA8aGhAc29kYS5iZXJrZWxleS5lZHU+iQBVAgUQKw72J1QDRxQAIuUtAQExNgIA
pNqq5+d9cxdYphGVuZMGcHoNrxqvkMmzhgjKvFbC956m19lSF918/F+CisTNr6L/
sJkmyARrqZPivGPhYvgipYkAVQIFECsO31YN91aF3b4N1QEBtDoCAJvDbP1+ZbG/
RDXQexxvollsOBfkp5hrfY+KQ/2U4V7i8Kef3Vy5j+RzXcY7fRLjuWQLi+yykBLh
mVkArKv5xvKJAFUCBRArDtn5zT/tLvUlcRcBASdWAgDaGqLltSctfJBz/cwgbAFe
7zEtZTfghFA3q8vEHsdHhFP5Vx0jHhwZozFEiLJHuoz9OKyuvxRKrKgnqlFVhSO5
iQCVAgUQKw6qUCmBKTQiZpaHAQH2pwQAsg59Mw1e9JxCD8VLOxLvtMuk4XJlHRNQ
U3FW11z0zrlShLwFSqOt3h3ag/A3EFZLB1j213JbIUlUuYzJO1yC1sjV7Xryd6D7
HG2R7GbL8WOLTuoBO4XQTtKu0PulJgbiVc+4CHV2S1QSUaEeWbPRqciSAwfFSGb3
1Jqu1Xu1mV6ZAI0CKw6peAAAAQQAxAKQzN+3TQJtcn0KEKd3H2UP4mNLSvEekmNX
kGxVmvEGW1yNp14cQiP+DHe7W0/ZL4mMs5+BsGmlatzIZm0lkZPPFP+mdxgmmH8y
A6Qw0VttCYEAjoSEr6UZ4sPVoPktsitLUjrQMk5tWfx8JMxKV9XK8WASwVjkKYEp
NCJmlocABRG0KlNjb3R0IENvbGxpbnMgPFNjb3R0X0NvbGxpbnNAZ2VubWFnaWMu
Y29tPokAlQIFECsO7UatUkpRhRl/tQEBgswEAIN3cA/Wobk6EkktBBSr3ZybB8zv
mA8Nze7jXLm6fgiMRGAhSB/79Q5tshc3pE7UtOzpHmTiZ/ppz2nRjkyr8CzIsEzs
LVDM7ctOT7JN7MxEBUZ3D03Zs1AIA6nzn1MfKbFTol2jXm0LXXafMixdpcvfV3v1
hGagMTMtMjjumiytmQCNAirPdYEAAAEEAMoyYy8lL84DlFK4IRmYBwfSFY8IwWia
0J3cKPHKyQVligPKgUnfh+Ky6wN6eXAeZsbEjM6VMXY21mMaRec3IbzXok2UKQHy
FNUnL74J4iH1+hGw0hO89bcDwFeFXvaFqcNTQRF0GJOSSIEiz970fqUOo+esZzKe
azP+2tnMgvmhAAURtCFEclphcGhvZCA8ZHJ6YXBob2RAbmNzZWx4c2kudXVjcD6J
AFUCBRAqz+Q0VANHFAAi5S0BAe2PAf9bKSOk76/vSFirkK/47CACCfDbkj1bvBVz
fzPv8+sY6pwi7xjEneropY0i6enwBWOWSP7r9VoqF90Ib+vjEFbxmQCNAisOzWIA
AAEEALLmQZNts5rAUk5NoTJcbpsNpCazDysVO89QP70nxTniGaPGx7ywfbJN3dWz
CjQbpC8ZwALcI9hexxlxz0lUvnrPy1OT5+lNIU68uvDYWU7s+ZrnGLCA7vGgH3sS
PQbmaOu7QUu9o/ynJc29NABMrNhAYdbZvY7HxOsAk+sCRcQ1AAURtCJEYXZlIEty
aWVnZXIgPGRrcmllZ2VyQG5ldGNvbS5jb20+iQBVAgUQKw7141QDRxQAIuUtAQE/
SgH/epfSUEmghODhSeVUqdJVkpYpjZu7c5j+2LGG5CWU1jjavK7t8HpY5kcyDsUA
BF56S5kQ3fiyNiWxTpKtoSjgiIkAVQIFECsO3vUN91aF3b4N1QEBn1UB/2DJjDCi
jIwyjNODzLr1pjmb5UAaWFwzTyg0F+G7iQ7GgjfcuaEjd8NSaQloIaqawdRa482M
LqKeFMeeSPcxrheJAJUCBRArDtegrVJKUYUZf7UBAX5sA/0ebDd2cPr3EN/RWC5/
4Nie4275BmEo/07Ita2XytResauQLP9JcNuSxLLlNRylvzXVS0EiQL4heek140ug
TSNZSp7eSvjdxWUKhNLN4/5OqIm9IkVK3usbIaC0HVSwwF9xx4BOnzwuOlbFLxT+
qKA3C72ZvqEvkEnR72svlsX5RokAVQIFECsO0ejNP+0u9SVxFwEBvGMB/jk538BE
2nV/QwBjEOXDJICNwbaZj0aLbT/kMdnW6ktGEdHUTmMHd8tyTGL4D3sauHWchUYH
cGkoJXBd8ZtdyXmJAJUCBRArDs7sofVDpely8BEBAWVnBADckZz3+yOADrLxdYbE
kWdl3aoc88717F7mpzi2BRCKUQPVMic6yANCvEbttb9jJ7hrLjf/J4Lhq/egY7n7
aVfYVJsgxVahtyrfXPTdVKbicrbRqctozpYoHXLEPGzl9m0YaV38EPONxLGTlgUS
VFXR/SuxHe11fMxqnNx263Ydv5kAjQIrDsT9AAABBADdzlqPkaE5J9VSntGSJwPb
9XUmCUaSMOwvaxGCUdTiJjlOUVKfIoUoGgWvo2pS9II31HP3+YWBDyhYj4Cu1odb
f9IrlLv6u5G5BOuYSewthAMp85n1VZLjWERKAr0883dgBJ0FE2QYWxppSSZrmtbW
rSYCSXOcQX+h9UOl6XLwEQAFEbQkRS4gRGVhbiBUcmliYmxlIDx0cmliYmxlQHhh
bmFkdS5jb20+iQBVAgUQKw71jlQDRxQAIuUtAQF3KwIAmVxMJUn023kdxA003HRC
twXqZTY53zJbR/LdXVjgIgDDd2FUzf9vyvU7TQWKE5qJZoB4H/xbMIYozuAUuRDg
m4kAVQIFECsO3n4N91aF3b4N1QEBHvQB/iGuaRAqESEPvygmwGP/a+L6MANN38nQ
vZkqbbil6mKrTweplVlkWkEyC3xxj6mXQGrmuxo6dZD5mz1yMRGu9tSJAFUCBRAr
DtWfThgGN4+JhjEBAc+mAgDg6eWttKQVvu7yvwdCHryImG8P4g468iCdPSIux24a
PWsdtkH3v84FW6ZhDOaHe8skliFtn279HnXnR06DxtTUiQCVAgUQKw7FiK1SSlGF
GX+1AQE36AP+MunJg8k3m7lwAWAiaCPQAJ7m970en78QuZq28wdubULfLkrNKE0f
pXcW4RCLEP9HPgsxGHEwdUQ0uNHzQx++rdDkDUyX9n3gp8bNPI+qkFItXfwXgl/d
2y0lN9VaVAQ9F4yfn4AsMHX68qz/jfRtDEEemHXlE8JzyTapLpnsayuZAI0CKww6
ggAAAQQA1/vI2320Fw0uDvKpV6CtFAnx11BNwddQVdK4sKgA53dxAyFjZ08m7MsO
1nO0r7LyJHOB+uTMli1lOp9BDhBECoG5aSgKDsM5fxtawEv3Fi1/yv/Sfxda4uRR
z8Jmelabg19dquTr8uVtfx9iyEKv1ANp24wfn1L5VmLN1FTnSD8ABRG0KlRpbW90
aHkgQy4gTWF5IDx0Y21heUBuZXRjb20uY29tPiAxMS0yMC05MokAVQIFECsO9bRU
A0cUACLlLQEBbVECAI/wy6VsiYLrJTu7CYP7b7d0VGx/6tNlV428R8+4t6/TTLGl
gaj4vwkqxxJvvfB/iC0mUz8R0cc8symHqyCFYCCJAFUCBRArDt6sDfdWhd2+DdUB
ARdRAgDA2NCvsdWQ8un9vDO8RyUux/cRQRt8s3jbURoDfMQaxeRySiOZAfcikHlk
jYv7xs/30exUdxhEM1ge/J6xkS09iQBVAgUQKw7VXk4YBjePiYYxAQEK5QIAjJ1v
7ZFDLjRHBnD5BbVmsEI771CjsvHOg7nLjpi5daB0S7mq2dIbxQP9N4N1Pktlyx4c
QF5R6SjS3y9uyhNnCIkAlQIFECsOz4+h9UOl6XLwEQEBdG8D+wRPT3GD/RqlIZ4u
TnbZADXZqvbv4N77YEh3h7SV8hj36E/BMY2ATNeSSlQszeMvw+Wf7qP4K8TmBNqR
CynBlfGIAut2Mq2EGFXnnczpTznKO5AnuueA5B1V2LhzUnFYPQ1RYKQwI79CXE8A
MHNuzj2XyhrZM7eSfSy02C7U8RkWiQBVAgUQKw7JjIxutC9MEx9XAQFbfAIArqvT
ilFa/ivgvjX9yQLiMqsEYGd8JZlkQMxeDgPzEHifi7UGG6Eqqaf6jHK5uWlBX4ae
OT22GOp0l+2IgI2ynIkAVQIFECsOwZTNP+0u9SVxFwEB1T8CAJH+YlhjFoSmUAmP
8QUXojTzrNJToYNpHgIhuYQ06ScrJXD9wokCNZKvD+xBGsruSZMNlOmfWdDDgoW7
gLGVuP6JAJUCBRArDsB6rVJKUYUZf7UBAUtcA/9deJQC4FhMrz/Y59gTXDRmFWwF
ESxyMln2tbRnC0oJRle0cMgFDdC/CioiIpsBO1PVzJrIeH1sTCXU/DaQuf9b2X7s
3I7tQYw9/ZjR2OPkyYpv3rQn2Fp7POyhPy1Nv36yR4idrA/NUC7Ctt/+4jG68528
ksEvw9pbuVhNBcfn5JkATQIrCB+kAAABAgDEh5wtpV7xm0Owqgr8XYiLC+7JMot1
EaZO3nfjB/k+ckrtoZa/KHLuU7wKY69vt8RJ4exsuD0uU4xutC9MEx9XAAURtBlU
aW0gT3JlbiA8b3JlbkBhcHBsZS5jb20+iQBVAgUQKw71XFQDRxQAIuUtAQGCLQH+
JVGk8iVvPLayNZWg6bSvRH3h4y3GLPFzVvA89ZMHb1xgiW29LyiscutGD8qWPpsb
WzyZsqeDQ2hFJxqk3k5xm4kAVQIFECsO3kcN91aF3b4N1QEBjmkB/AvUlntcDgBp
MjTm41ABJT9wVIs01v2jzDNIykcHiUURKEkYJgDyd+a+bdA4GawdaCnqechXNoLA
KDplzZ/eL1SJAJUCBRArDs/9ofVDpely8BEBAas4A/9NRUFfg04khWbB7yR2HXlk
W6hrPNE9ci7iVKumjV6KJ2FyyC7IwOyXbV7AUOPyo6LB1mChUY9jXjB5BpNIIR39
R5I4BhDMEPBOBwO/nNapGDiG2RYEGwOFBa40IL5KhuQR+v+5Otc0hnLaH1tS0vrA
JHKM/s3n0kkMDQN8Qr0agIkAVQIFECsOwkbNP+0u9SVxFwEBK28CAJhatLqceA13
D6svwHB2XonVwzmkPt9L4zx6eIj4eAmpDqAf61KxAG9okz3BLwQa+vDZBztf6oNl
pw5suRf4BPGJAJUCBRArDr/RrVJKUYUZf7UBARiRBACnY6NN4LGspnygnKd/cLjO
Pu3cDxlaZRtLxoSrCduP7ANciUgYuobyInCP5qS94tBrK876mwR2KTohXxt6D1Tz
qsoeyu72Yv6K2OUwF49kbcZZHj5ab4Wkd/eGEu5oYIHMAzpa7Nlu14BDE+AXKaIf
dzT8qB2jEE5O10bD/8LA+pkAjQIq87YaAAABBADS19YljSbdxVnfyXLFxYTuMo+u
QuDxyWux/8fq9PcKXOTdsI2d4slSQHqLauxCbZywji1Qv0f2HVvBGxbUcYfMD3DX
edcRYL2LqtSOPIbvX5N2TScNkfaHnC4gYtVKCdiZfIldEY7VivXQCFAGjmpnOh7B
FeQ/E6+aZmGKlWth/wAFEbQuVGltb3RoeSBKLiBXYWxscyA8dHdhbGxzQG5jYzE3
MDFkLmRlbW9uLmNvLnVrPokAlQIFECr5wtj/yyWVmRmdZwEBhSQEAIAuvgbU2XaU
JTwWPCE/kMwgvL8O2PwzGMVpBT6b0pPfH9HmJizoAQgfpS2IzvT0JvMSVdd/AWis
x29JKmPZwycsuL9YhC/wiS2M4kx2sTWB2qxr3qxc+nMQ6MpIgQSzxfTgfNjRFlRJ
1HKHLz61auLuaoFpSkXN/cR1dLajeWQBiQCVAgUQKvSxsG1tOFJzS5pZAQHoAwP+
L7jbSlXX9gXnC4U4nVZRWDO4uvydEWTcKNY8/IxnejhZ5FJWg2pEjzKbAyw7Ilnk
3SvdRBe322yRbstdunwoMH7pVllwoul9ubACq4j1jgCfC5GkJ3Zu3bg8fjsb6UrZ
FUtpbaaCfp54I1qmsxhcPI3cppZxTENNw0hVXe36X5q0IVRpbSBXYWxscyA8Mjoy
NTMvNTEzQGZpZG9uZXQub3JnPokAlQIFECr5z/T/yyWVmRmdZwEBNY8D/R0c6RN2
lX4iXO93r3h+XEnFfPHJATKlzgwY6thmAyyFoUZx/zpeg9tAcawv38KY7M8cI+MB
DlmKg0wjs6vlbSGug+FlNtCyA58FgnerA4lCyKBa9vvQj1eJvXl97N/BKRrWnH0p
4+xPpITuyRszwBWjfspU+bFyluG4W46zAgAPmQCNAir42jMAAAEEAL8O8OQ1eDBh
W4eiV1iF+TapS3dz3kIQE9jTArEPg+lhNRa98mm6O9ihGvue6tMmgxPxOczMllOh
KlBOntvP3YdfeASz+z99kzk3wCo5o3eepUKxb7RPRtdq8AZKMHuDUhDOWeJbW6Nh
itUzS80AdJdJXlkj2Sw6DTBkQouPDkHHAAURtCNKb2huIFlvdXJpbCA8MToyMDMv
NDQ0QGZpZG9uZXQub3JnPpkAjQIq0o5XAAABA/4o1Wk45VOtpkHV8MY/mxDt8KnT
CpGZUTbda0ovFTkpHkNBu+ymwXiDaFQkyItdmse+KuwDYSgoGvmZAcQFU530gUGV
3xYf+VzMc86pOzU9nyipWfx63+HA3fFWIEpelj4clTvhKb8mZ+R3sxiwW68hqQnJ
aEpowXMHdoNaWFSIYwAFEbQsUy5FLiBCcm93biA8c2hhd25iQGNzY2locC5lY3N0
LmNzdWNoaWNvLmVkdT6ZAE0CKvQ7SAAAAQIAtwhdLpYOMc9jYuiP/HKciGbd5xf/
Ko6uE60qJpgkFrpor22K4MkaDGxnCPMNvWFRWyzlFMBLzZ+Zh6dZnnUf1QAFEbQn
QXJ0aHVyIEEuIFdhcmQgPDE6MTA2Lzg4LjFARmlkb25ldC5Pcmc+iQCVAgUQKvRH
b90U2ry4hanxAQH9UgP/a92Or1E/wmwL8IQ/KjaXOBK/ZZfCF+KZb8o1TAE/85am
tZCI0djGdgmT/GWogiQcC+OV5kbvyJZystc7F5vck8AnVzjurVKydAlxjXTNG13g
JLG7fIR4EEPu+Au+v3kOvZNXVL+RVPcGqppLb7acyJxxch60cK3Y+klSApZ17tiZ
AE0CKv/a+AAAAQIAvvIzkJW7QJxSrajJ2/nbzs0cUzuRu6zlUgV1RlWbw2n3tVtq
Z82m1uW3Y4xuJkAo94yGPt6ZaztFsaCuUW4XrQAFEbQ0SnVzdGluIFZhbGNvdXJ0
IDwxOjE2Ny8yMDh1c2VyQGZpZG9uZXQub3JnPiAoY2FzdWFsKZkATQIrArVNAAAB
Af4zTmMzdQdmMzsZSv2W+msaDmhpT6uSOw1fRh94XBkTeTehYk+LES4Yud0nOa1H
WA2vJhUHeLarxRuqx3E/C7Q3AAURtCpSZW1haWxpbmcgU2VydmljZSA8aGFsQGFs
dW1uaS5jYWx0ZWNoLmVkdT6ZAI0CKukFCAAAAQQAyYMMahMpKeY7L7QkFL4t/YnM
6UgzXJR9D0CltEaVxwCaGzY5Vs8phOAZjl2b14AyQCUPj0xVlkZZG8brnUZs369f
xtBpjfBTlp1b7MbWnZ+kgaDPvHot0muyZSQWGyRbTjTB4l9D+HBguAdms2aldP7E
DEawR+xCZkJHNGc7GNEABRG0IURhdmUgTXVuaG9sbG9uIDwxOjEyOC84NkBmaWRv
bmV0PokAlQIFECsBFxGbmjfV9XLGpwEBCTUD/0b+KIH7mflLLECq7rgGhJ9k9KYN
iKhy0gN2p6QOJB4LzY4vu1Wantw5pu/VJdkCvSiWCEom0IFi0gIYWqR5aBk5LC3D
eQVqEo6drJXIiY9C51rRj2P7jGh1QPjd3bK045UrOwWnFQ0ypIWLYQZkMDvXZKfJ
5XtblJ+xY7XlnidFmQCNAir6ffMAAAEEANIvssTzJGOUrwqqCwRn5RRRjMbAFovE
I8wuwzHOKxqZKVWEOyshaVsDDO6dwAgtq7BOixvAKMhiGYjT1EjABdkveQmJ51pn
nNkVADTW/LJg/xDG+dEbXdpoAPIsDmD52Qa4hQT73g+E3K+BxMWHSuROX0tUDugH
HYrYMBOwiJinAAURtC1NaWNoZWxhbmdlbG8gSm9uZXMgPG1pa2VAcm9jaGd0ZS5m
aWRvbmV0Lm9yZz6ZAE0CKv30TgAAAQIAsKjX0o394ucwqJwof00r25jeClo0Bne8
w+mIgA4fmxY5/Eq3Ru/9PQ2dQLSQav6QmxgDHt1MZzgL9HHetm47/wAFEbQmQnJh
ZCBIdW50dGluZyA8aHVudHRpbmcuNTEyQGdsYXJwLmNvbT6JAEUCBRAq/fY+M2gm
O1A7uw0BAdA8AX9MrWY70GmbQkK3Gpi8KKW8wRiiGUOYLqlOXpc/FWKKXxZc6zTi
eSr6/Lbr5AKuB3iZAI0CKvxezQAAAQQAuyduclSPeeuo313MBAD3RWFNwoT357ZH
5PdUlzSwX9SOeOaRojkjyMuELhkzB71r38UlhzYcpmQtBPQQh0kXtpDg2fWD4pdp
QQAQlR3K4KCxok/vux4Fq1qMxDoONMW0mLv5uzm3DfWxZI2PZ98gbO8+Z/c6A+PV
6jr803GUa98ABRG0HVBoaWwgS2FybiA8a2FybkBxdWFsY29tbS5jb20+iQCVAgUQ
KwApU/LwEg8VF94FAQGYnAP6A+7xlUecA9TMy2yY77zNzh+Yh2qmaAADP605FzMq
WpmgZfR3pC9vj4dpetpiOXpiQhPtrgWdKp9VQ8BV3ZGqSWEZqMQDQbmVNqo0zjxa
dm+WbCJs+MuCmWhqwebNYB47WdStIWww91yqHfg8znUIfADjPmDkljxaaxbrXcdy
SWmJAJUCBRAq/sW4JmxTO+Hhs4cBATzpA/4lNoC9awZwjAw1+LZnl6O0RIub8ngS
Wkh/FO34/GbFKPWjU/boiKktzFX2pjVjLCUHhYjuTyDf9I8FkbGKVByu2RZCIe1x
azjHsX6Vf8uAAkXmsVq/YZxS9rRxCqLRhdh1UCRLYy5CRpc2RnoAPLo62Se5J9uL
aIFQOss2RrNR1okAVQIFECr9KbnNP+0u9SVxFwEBWEECAIiUfg2md9cLBA+SpMIV
en5byuLWR7CSx3HJhQwid0IP7EjtZgA+bnmHG4XZTsHLH1kquO4mwrw4CmSxkgM7
kDKJAJUCBRAq/YGlrVJKUYUZf7UBAf4zA/4/wwJgR47BEd1k9FsAZtIjfqnqBQes
Z2GgpzrbEddx13iur/qwwME2qHRwG3bM6YAmReVKDx08nccxyJ0XtS8aWdJLgy0G
163oF4olFg6pjI+eCnGvv3aLSn7ImvNQ1VRXS4wAq7ZFK+FG8XmvcEIq14esCx8+
QohKA1CmE5syJZkAjQIqwLQ/AAABA/4rPr0YYY2zZVg11tuwTcnv8Br7O0ybaaQL
vFkyLR/sAHtO1bpnVK9Lrpa4ajWXrGgws3VjCKeiCEZTp+42AubMkv0mDf7aCWR/
f0doZfrRlAMWE6Y/Nrk86+57ZRETtIAu53rp6L+umiiCND/yUVjyZ34iqUwc/lmf
ARRCVtnsiwAFEbQbRWQgRGVIYXJ0IDxkZWhhcnRAY2VydC5vcmc+mQBNAiquwMAA
AAECALC76HwzAONUnaxlyj1TWJphHqDvZ5RB+EmFDJ7WSyEuj8tq0P8iZcRV5Ut1
W9tQO7I07DtJJq/BVQVm+k0MTuEABRG0IUplZmZyZXkgSS4gU2NoaWxsZXIgPGpp
c0BtaXQuZWR1PokAVQIFECrPoHpVBWb6TQxO4QEBnZAB+wT9j331mWhg+NuLcMes
EG9U1X1QZG0OTOr8tItwrA5CflpbQEIULavga6j5VJJuileTobU9Pof/LX6jpwh/
BgOJAG4CBRAqwm+lOHQrXMGwavEBAd54AsQJGC5ulF+heo2oqNCI0pF9AC9LGZCD
n7EtEqzzq/6vNQndOin1yYlUJ5Bbv8rDwQ5ZtX+GrgBVgvm57eDwLtDVK7UGjS6M
xAmOPOqxqb/vik85CvqjOv739pkAjQIrACgiAAABBAC/bz3yCNkLGb2BGkkuX3/j
sOIrDZhkQru04o+9fnvlgsE1rpsl39d8FaM3slpzoWumLvXDEpnrtYyMQwdsei9O
OybBk6F79HQ3qvFXo7GZSfLI9UArPhbxHgF4ASlOUj7wghaOYAqI16USrvGq/XbO
fE8kczRRhxny8BIPFRfeBQAFEbQjSmVmZiBCZWNrbGV5IDxiZWNrbGV5QHF1YWxj
b21tLmNvbT6JAJUCBRArACkN6jr803GUa98BAX79BACOgUTzwvG1eGQATSsKO7ob
8zOM5lzcQ6wFxe4RckXbySwvzwWYxuRsSpOvH6ZLf9YPDi2c3vGDSk9OYz7CPyU2
djVIMXJxy5ITuzu/Uu/wENEM9m7Zqkps0bltLpXIIch01NznTpy+YSM0aJy+i44L
5qAsuJ/vgKtsnZ8saMM1wpkATQIqu5q+AAABAgDPUfDi/la+bkvObQgiOnGjRJQX
X6G1/f9AConX6f/g+zEc/OiLMn35mglqfxfMorUdRWM23u5A8R9bGnaOb/KNAAUR
tC5QYXQgRmFycmVsbCAoUGF0cmljayBELikgPHBmYXJyZWxsQGNzLmdtdS5lZHU+
iQBVAgUQKuVXcxmDgsNS79YXAQEeDAH9HI0sBvKUHNcE2hyYmFFNmj/vkDHxh70Q
PNNGeH9RrOXuzlsULrfB+1+XGTuWCt95CD5r2pNrjqD5OAz7sMMamokAVQIFECrd
miSkkSFWWSDVNQEBH5MB/R74VxW6HxvNcR90m6n1BPW4PVRlF/XPMb+WkmMbxcC/
cy8AL//426liFpbGD0Qn5PE2UtLzsg5whuH2j9+gG5iZAI0CKrQ85QAAAQQAnyF7
QB+bkTWJ+PBTVNpa6QIP8Em1HW24UtyyHnc8cCRHV8IXab3OcPbTQzv/WcZDYogN
AkzxrBwE0v81si0Ld2YikSuNCK7+K9GTWeP1k3xttQSpxSyDmK6gqM5LgpZfT8xQ
LBJdt9yGCstanqWGoZYMI6VcDOOl2Mc2ZhtozJEABRG0J0pvaG4gQS4gTGltcGVy
dCA8am9obmxAbjNkbWMuc3ZyLm1kLnVzPpkAjQIq85+JAAABA/42Cc61+viyUFYp
0TJfrTh7hZL9pFavKvlkQGeGML0P7QFfx9bn9mTkT0c6HuPeAOAlerjU/DIeixmt
aSQkrXyduI01jCwcMXsRu2huAFZY1cbZRfgZGkV+72q3+EJYdo5H7RvDcMsobfJx
r6j/i7bRrEDuF3OkDbcud4z0nEkG9wAFEbQmUGV0ZXIgSy4gQm91Y2hlciA8Ym91
Y2hlckBjc2wuc3JpLmNvbT6JAJUCBRAq+BwzXE2hr7Q1SWMBAbCgA/0bOeyDLHgD
PCnPCSsPvwlLSybrlZHt9FYFxDzEK+fyyRDTn4LA3CNn0eNn6aLxqm9KwkeHcq8w
JDPt65OS8yVmNQpHu/61PKbuSvuaE9UULNdiZOmSPzY0xvjaCqwVj83Yeg52Go+b
xArNzisygYG6/hAoSnI1QjuswvJIKP/BU5kAjQIqwgaUAAABBAC/QxRn5G9merg0
FiL/PitJxqJoMKJDrlIzpZtKz9eKmOflIsn5N3zxBIzGgKcGDQgUCG0JEe5YppT9
PjwkMGxf6mxbrfNyQNA/eN9e2a3kdurijhg+8NfSrafZT1Zix9QIgEFaM8q5Yyy2
oYz1ShC5orOtiKsZaSKIhXGWu7M+ZQAFEbQmRGF2aWQgU3Rlcm5saWdodCA8c3Ry
bmxnaHRAbmV0Y29tLmNvbT6ZAI0CKq+n3QAAAQQA7RUWyuadmGYAsM5kQbq8+VPA
HmOozmzA6SEOokg4c63I26DZl8KmxBRhytUIqMazjNqK8SiJDGL7nfybA2Ev0ddA
r4jcdHbERLOkkSguK/raQwhzBVsTD1AC7FjtnTUoeL5s1iFhC/MFzNpW208l05O8
2ltQLNYh4pcQz3lYg1sABRG0KFRlZCBXcmlnaHQgPHdyaWdodEBsaW1zMDEubGVy
Yy5uYXNhLmdvdj6ZAE0CKrFhOQAAAQIAt94dinTILzSzVJwW8lKmPl5IIA76GKG2
d4Wuuf6+4RxJq+EABTCkhQbJXY3yf6UVM+ectzjYyz5zw8lQ9gpUjwAFEbQjTWFy
YyBUaGliYXVsdCA8bWFyY0B0YW5kYS5pc2lzLm9yZz6ZAI0CKnXWfwAAAQP+NKBR
j6NV8GA/na8KBlDFOSM/vbczlzPSj+0zmfk33b/Gz7fW4baamIAe0P84Xz6XqEOl
WXjQQN2iueXmIp/9fR/xfJxe5LBelhRPazyNrVMD5/Hb1e93Bf8X3p0ZtkpfZnJt
Mu+sSkkJzEAjYdudiNPmD8eNm7pSJmxTO+Hhs4cABRG0KFBlcnJ5IEUuIE1ldHpn
ZXIgPHBtZXR6Z2VyQHNoZWFyc29uLmNvbT6JAJUCBRAq/rsN6jr803GUa98BAXPQ
A/992sANN84YkupfvlynGI2R2NvVvb6tQAne0lg8CQjf6rdjTWvHE4hDJZW0mqoz
G2CGmi1meXRXwqNMUaNYBQfxoAnFbaboPj0N6qdNgzhQRgppa72c73Ayj7uOOxWn
wsDCsHxBgF55/E8Xo5F3m3U5r46pxsQSNn5Sos9lUPtfV4kAlQIFECp17mLidd4O
/2f3CwEB85UD/0VJnzQ4JC+Kvn72XCxTVODFA4PjdnVRZQEtOR8qMKd7oixVjQQ3
DFpOYEi0ASx+Zpgf1Pja3URdtBXHpYBVxG6KlriJxFkfIUrZ4wSUoHA3cah9fm50
AT85KKRz3fwnkE4z9+nDpDW0lhfvDG+vg/KmvZJPyRSiwmM8RZQ1/Hb6iQCVAgUQ
Kq5vTneU/RvzKz+ZAQGyDQP8DQo3C0Lo62K1YdMjgT1WK58qsfQS/jZnGEHyDjSY
PYzb6UQ2JyWmbPsfx365Z5UrMByO0rrOiTtuHtL/4GuA2xCGRLHy7Ci4JRzTKIOi
LFW19KSlo0gK3EZp0Y+I3RMK0Ne9nvkcRD3S4C6vGb3XUzANlZei8msyJjPBd44g
WbyZAI0CKv2QnAAAAQQAu9hHRyLEDQrqpXhkP/uKLGRH7g/Bk0bSuxNPdTYN4c2P
p+xUEYkvQ3JPX3Uhwh/QXlVFwarLPL87CfpbZcSAwWoR3x2z2yy5BXAzzS5iK5+S
efBN+qd1FzEVPSwpJtlQODuSBwadH2dpQeH+HjjiHTej4ZMy/X6bhr7UV33/hTMA
BRG0JXBldGVyIGhvbmV5bWFuIDxob25leUBjaXRpLnVtaWNoLmVkdT6JAJUCBRAq
/ZHM6jr803GUa98BAdg/A/9a7IZVESRRqyZVNhTRQkWNiZStDWxFgH3wCzlyCHzt
+H4uYFNzDMGmwCYRJ9HtOobicbPv8ZV150TkuUzmaHkAyGbnyTl4mNL05W5aVVYv
FrKCaCjAHQ4+cYNfxr6PSPH83oUsb2l8cFRLov0v08tUHNGiEinzL1blfUQCb0C+
fJkAjQIq/SX4AAABBADD37Ztb6L9d7+rrxl4g60R3ggHwJT1gUK80FlEJz0AG5ac
jZae6QqRrOpx83rlCIBwYabbzy3YKKo5DwENvrlPVvYhQUMoQW9xbJ+k+LXVKGWe
/mp+eqt89YrKtXe8S/rvEEhljJQHl3icT7MTr4mgnSfgNOEHDEzC+a6J/vTBcQAF
EbQoRnV0dXJlTmVyZCBTdGV2ZSBXaXRoYW0gPGZuZXJkQHNtZHMuY29tPokAVQIF
ECr9J9HNP+0u9SVxFwEB++AB/1pymCaHy6JkUX0i4mzw0lTqDImc2L5TX6Inu77z
QMHiF1u1Xx/2G4RaTbceMvozcsBKQY8KOM7ArLwODnsoEqmZAE0CKsyOTgAAAQIA
q+wDIbTKjxexmByf5bjYOirUWO734ArD/8QW78yCXhgsuwE99xTL6y0nEGnJPynK
zXj8SOsrhh5UA0cUACLlLQAFEbQmRXJpYyBIdWdoZXMgPGh1Z2hlc0Bzb2RhLmJl
cmtlbGV5LmVkdT6JAJUCBRArDtcMrVJKUYUZf7UBAYIbA/9q13zMS22XrfMEpCpe
Rv+c1ViCDcvSp+znkaKWSYY2LglUBpUvc8SlyGoeMwFtitkdoIG0RvYjL6+M7gba
T+d6HkBqO4f7QOpH29ZLqnbdQi0aKIk+IrIkOEb16nsqy2ojbL86y/t4RdbVfnQf
b8sFI4ormEuxUGr54wmP8eLQxokAVQIFECsO1QtOGAY3j4mGMQEBtuMB/27/Gkgl
54VwZnh6EPSoCUtDdlMFr0E1+CyaaVysmUiZtPgWyKlkdVF62L/1NlLQWNwdudWA
9pyGlN/PtPMG62iJAJUCBRArDs+5ofVDpely8BEBATCBA/4gn6k/zL1i/oeMExVu
Ric4S6qRxCbVGqNEiuravaFRMtIST80yCXZmfStvXmbtOx4fMKSZyFP8bz+MImNx
qN9KoJ9qa/BXNUCBcmoDpiwrTXGTIpG41Hp4oUt1PRbKgxfYO95amJZWqOK543wl
sG6c8ECQ16r8k7LjFyiK7TLaNokAVQIFECsOzqWMbrQvTBMfVwEBMzMCAIfQHd9B
QECckjVbLuqCjEQ4qMkTswvGxx3+r8HwPg7nXazNXouU0MuOyFMzVMxYq1HpEimK
t7Yw1NxUfr3EV1mJAFUCBRAq/QWhzT/tLvUlcRcBAS+bAfoCJ09VmN3kQKTl0FiD
gicnL4AdapE9Ae0PhzRicwrpsDgwRZpMWWJ3I8x45aAEIx4WbrE++635ZbsKNv09
/h/nmQBNAiq/U1cAAAECAMyx0/jdGADqY0GVjnTJU0/xVP39MH6H5PHcD7/xbmtb
huvNOm+yejcX26z82kEHm5os+APY+2Reb7yMu4/P46cABRG0GEFydGh1ciBBYnJh
aGFtIDxhMkB3ZWxsPokAVQIFECr9BUrNP+0u9SVxFwEBKVUCALSFLYzsX+JmonNe
y88OIcfHVz6ofpwILDHNbF7aHRbI8xSsYENF46Xl3i0gX/81Yryq4EnP+45hUh3c
8+enppGJAFUCBRAqzdeLVANHFAAi5S0BAR81AgCjo9ianON2xHMtqh0CNtRX8Jlp
wJkeWzHTYnZV8G3INAdCj1dxs81HeN+JhRFp2toN8zIFB+Sj8olN0bvGtF2kmQBN
Air9A6oAAAECAMguSk+WTd4dFM/x2ujb61dxXacQp96qO4bzv1HakFjdntjYOsgQ
dI/Q8BEBmvDKooQutKfJVwcOtFa98HfmaOsABRG0JE1pY2hhZWwgQS4gUGVycnkg
PG1wZXJyeUBuZXRjb20uY29tPokAVQIFECr9BHbNP+0u9SVxFwEBRTsCAMkpIc7d
QvPhEOJvIiqAeaEsv8c5GzwnF0dXzUA6yX45jRa1dp9Apb5rURSPkgKKLhCezeE1
Q5TAGlo86afa0SuZAI0CKtptOgAAAQQAz+NON0lqxUin3pW5MDURzQcJ/jOX/EYg
gxprQ3iexD7A9gAj877+rlYd4k/iGU2BO4A7g7si2xOlEtxCRRIPI3i5BB4TOv69
qRoGUqvo1OxnYKeYNHqgTj1QlhX5Kxm3Bo46biqsrtbsbxJn9wD45t3SP5Y5Gn7c
eBk/WAnAmfcABRG0HERhdmlkIEdvb2Rlbm91Z2ggPHBhbGxpbyFkZz60GzxkYXZp
ZC5nb29kZW5vdWdoQDE6MTI1LzI4PrQcPGRnJXBhbGxpby51dWNwQGNzLnNmc3Uu
ZWR1PpkATQIqxL8cAAABAgDFJCx68eiR+OQTHeG8WQzUDtx6y5oWUr7Bycyx/fvd
AU27l9yr6NKUiwoffJtgG7vy7aBw4ICTisURnnvuTwxHAAURtClFZGdhciBXLiBT
d2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIFECrbtYfidd4O/2f3
CwEBYJwEAI0ZSppkrwzGVFijNgUBZqahwYmgoOziyhBZ4PaWRsdqs2BwmTi/mvQN
HsTfT0QLVemxJvfhfFaDhKVchd+OlycMBNXv9dyBExxYuyXfX247MPL6EBas+vV9
qfMaBC8WLakpcHzkN0uyTssseP6dOHxvyWbkSYnFWlCEZQyhyTydmQBNAirjBTwA
AAECAJoHYggr0xjX0Dnxmjekwri89SlHgxvMjWHHF80xi5MXQNuL81TRDiAIsI62
/a6wfpRNXG+6vqJmq9iQOc4yVgMABRG0HEtlbiBUdWxleSA8MTozNzQvOThARmlk
b25ldD6JAFUCBRAq6qj6zT/tLvUlcRcBAYRvAf0fpwQTqCmaLMcJ7x6Tlje03N/W
NfFL1pBZrmyv6AppQ9/2Qxo2aGqyfaDlhwX575SLLBxxVTRJS8oBFfjdinfuiQCV
AgUQKuTPZG1tOFJzS5pZAQFu+gP7BWMYR7lWYDRLf7tQCp9PAN3sixKV2mqBCAd+
cjkkS0KX2feu0MBc6vMtHxtznIvNJApMs5Vkj8ehJa+KS1mYqfxOT5u8pL2qW3X+
AqP8W80OPxvnshj5WhWc2yciSgG6FjCmJZju8u30cQjInLLi4WODDAc5ils/i7+K
kLPgQOSZAI0CKtKJywAAAQQAtDyXWONtwBLEqR2UcAJ9oT56b2L33pKizyjHnQmO
Fk2703qZ+3xXQCmnR5dNgAS6afP4JVUlePMxSCWgazVmfK+qRPdWFoXoLJRJQXBc
jKb8hSRu6+zeqoRTnnIZOXWzaByOCKrIv/WOY4h1poxA2tDj/jHbyBo4VBgwldon
7DUABRG0LldlcyBQZXJraGlzZXIgPHdlcy5wZXJraGlzZXJAd2Vpc2Uub21haHVn
Lm9yZz6JAJUCBRAq3itGbW04UnNLmlkBAW1uA/4pJo5bNCXahpE6paQ/co0mrOzX
j2CzupEl0wDj6ylGJlLyc/DS5UhRqbRqk0kz+686K+1IfOwvUAG24iTZ9TIkur12
E9DaQ7K6qX5g6jvpmUuga8eheT8arfDo3WoFAOoim24Fe1z1KOR3H90R+yLLdZ5x
4kW0pecjRCl7+gnUbYkAlQIFECrUa2pKtkq8lXilFwEBheAD/iQ0GsKaQ5gLXkoS
hegXtuDBqQcsWJyGEV8h6SjiHBseOUuxWTqEvphs1OFV0WBfa3h732Bp89Bho2fe
tiubRSUkrqRe3HMQYpywNxGJbV/IiLn28i8KEugW9oJl+meZHw1XH375cPEalhQM
MaMLOkFPFb2nS2uNAZhI71aswCIImQCNAirkL4AAAAEEANAomYnlPXopnms9RtU0
ln9CiLJljssOeflC9A+QIDujXhPTyApbL6VPqSUSoFF/e72xTJixyrwBQhw5lAvf
vQPEiGIFQQYxviF+Qg/+6/JVvLCjvnGVFl9kKTEYVeONxBNGiaXuSE0VMQLx47iP
9AU+wYw62aXmTNtW1BUtX5BHAAURtDBKYW1lcyBBLiBDYW1wYmVsbCA8dWphY2Ft
cGJlQG1lbXN0dngxLm1lbXN0LmVkdT6ZAI0CKuN2gAAAAQQAqsmezlzittexSL7T
2q3MtZzoGVHC6q2qShatJ3n3WxBy4mgfotY3k3UqFKnoTIt/mYgyAg8blResgagg
7K5d7TnfJiwtz3ugZFuIAouiiNl6yKW9QwinOBLHI81kpLthNJWIiwH5IeAU8M8X
G06+mI/QiY1W9SSeOmAzDoV/mL0ABRO0K0RhcmluIENvd2FuIDxjb3dhbkBjZXJp
YW50aHVzLnBpbmV0cmVlLm9yZz6ZAI0CKuAF9QAAAQQAzzFX9DWfy6FsVCV3/mt3
UxtMSB1vhQnym5+aLPWS8EE1f7ZaGBqJclUhKiI0uxIMbaBX4qsycjJDeaOHLcQl
7P8XASn8Iom+n3yz53M+YTSJ5MpYVLum/StGQ1eZH83aHk0dh/Eg09nt75/xjpQh
qLDsyUtnKyn8J4rCvohckiEABRG0CVRlZCBSb2xsZbQTMjAxMDoxMDAvMS4wQFNE
QW5ldLQSMToxMDUvMzYuMEBmaWRvbmV0mQCNAirX8PoAAAEEAMR3OWKIVB4xzN1B
o/dXN/b7J7Rs0f/HB/ptEaJE+/xfxd81zXS07ph5Q/djiuIXQD1hKfsVQMoMiig6
fiwRSOCUz4cdojRC5srpuUrrCTH9RVvtpusyCv9IMzKoHdkA2+hrDLBasZQ3LZyK
8/bqmQibg9y3x47nMPUW0H0hLsVLAAUXtDpHdXkgTWFydGluIDE6MTQzLzI2OSAo
Z3V5Lm1hcnRpbkBmMjY5Lm4xNDMuejEuZmlkb25ldC5vcmcpmQCNAirV5D4AAAEE
ANrK4Za9zBHUPq3EL2rZy1+ZoWWrwlbsnOOBM4Z9RBv5HdL2n4Pd2ORCU6ZT68qz
3gAZrgu9kYSdpHRJ2Z7AMTvkpCc19/xZZ1cmrbu1VaLEdlnJeaS0DIWmM9GYUUaC
L9RiKgJzJnA/0mwRQ6bkpM0w+DI5+0zxyaOpetHn8j2VAAURtCdNaWtlIExhc3Rl
ciA8bGFzdGVybUBvaG0uZWUudXR1bHNhLmVkdT60H01pa2UgTGFzdGVyIDwxOjE3
MC8xMDlAZmlkb25ldD6ZAI0CKtz3+QAAAQQA06sFNgWhUfPlRJcrkO1V5Bp9iHFT
2WMR9aak0SOxvh05wYmmZdnU9uApEg+bju0zwD8RZdANYQ87dN3L90jHSJH2wMVs
yNXcJ6NPlsuc/OKbn7WD42lwNPA3NS/KQImcw2LcfeTQQiqoq420xbjpewVAdh2K
Y7/ivl6qbtuRADcABRG0MUJhcnJ5IEthcGtlIDxCYXJyeS5LYXBrZUBmMzMubjEy
NS56MS5maWRvbmV0Lm9yZz6JAJUCBRAq3YSHzIbhwBREKj8BAQQeBAC79vQiqzvi
lJEBuXLhC1JSukw8ky7R4uHOgv5GcmHiyYHs4hq6aKhpUzgybsmI+HClBO9hIT7h
ajVjGYg15UyA7cGytDOo/QjLo3rsNLY5ad7CmCvGgA/0q+DvgmjIzNK5t0Mdgh57
QsV69BXwoH3nKeH41dX/UkKKvh9XkbzoL4kAVQIFECrtmPXNP+0u9SVxFwEBxp0B
/jgy0D4FzaEMwO/yb2LYW2DMG+S0t1Gk7I3JQMmsSzGf6BWMv5h7EZRdk94yRDT/
62ft3k5JsGUPvwa6VLEf6cWJAJUCBRAq3xMSbW04UnNLmlkBAVA+A/95zn/dHFOr
D9JhL6tSsQbwKRV7kb6Itwmx3ECaJxuhH4uGVuDCwu9bkSLvILGsCu3t1yuw5Zrh
ivtC5khq8MID7EuTSpcWCI125uSQRneTThuH6mJmOjj3dUWPzRZKLa1kbiPH4wca
h8sMvUYNJjiPyXryLPv5s7N9VeVz7jcn+pkAjQIqwncSAAABBACvXC8GUY83UrGJ
PzD2CG098ZiWfu9yMTPKz2ji+TK4e0KI5M13DWa+1bWPm+WWv0dYnJrKSmQ7sYbK
K3owd/byvNIYC6QfN2Nl0C8RcNk4lduLlOlEWXzQuLKPaZhqx9uahtibSnHmf705
lDnXN4ijPAd5ooc30tf/+yHKJrNc0wAFE7QtSmFzb24gWWFub3dpdHogPGp5YW5v
d2l0ekBoYW1wLmhhbXBzaGlyZS5lZHU+iQCVAgUQKtBLM//7Icoms1zTAQFkqQQA
ndM0KgNy0hBQEI7QUrxMBE1nNzvg5hpoqBO0nCmlckhzB1JZfUATCU9zkNyZ9Vif
FuGSnoj1HgPYl4lEDOtASZm8MUupbSb1T1JMdkM6C50t9WjPl6LIj0tldHLGefDq
pOTantqCdyz8WuRqUJ7S/JKPTNQ0t5LidT1o4s3/M42ZAE0CKtrZngAAAQIA9UJP
v2NsjfiajySZ3ihHPNNUA3J+pBkedcQ6JVpsB1/BS1NVx8KGKivpPXgFtYvtR4oB
EZEVlLCZWKoJnH6ZvQAFEbQiUmljaCBWZXJhYSA8MToxMzUvOTA3QGZpZG9uZXQu
b3JnPokAlQIFECrchQltbThSc0uaWQEB4uIEAKN+Cl7wUI/1tFckEfZc7WDbsN8F
3wP+mZVanZOeQi8KlViSsatQ7D9E1LfjNo/03BE7vDODpm3l/RHhQLwfDkMuS49E
BDF0qhIn45X4v6ImUrF4Fs1MRPQE10lnoWQs2CjStPmSWhG2jvL7xMPSy1r8m4n6
dxGcyxCFML8ckyU8mQCNAiraG3wAAAEEAJuaF6NRnKvVEU3edX8OUxMdb+k3ZRfd
2KM3b7+7mahkMqTfKj/wiNpqbnnV/pKoD3jf35KjO0i+Oa5spGCc3I7VCDDcKhHV
6iZcYD0lpF2ySh5sUFsRGqWO4oo/jyzrNgzV0awrg2IYT5u7ClLXbpuZGcdIKbTN
dZuaN9X1csanAAUTtDFKaW0gQ2FubmVsbCA8SmltLkNhbm5lbGxAZjIxLm4yMTYu
ejEuZmlkb25ldC5vcmc+iQCVAgUQKtwvCB/LuW/nlgUBAQGbJQP9FE4TZ5Si7z/2
t9bcE46cSm6B3GmrCEO+YC6SNSfSSaVnFTLJFr4h/TgkIWj1giTXTC8+ebB3ulpf
6E4MrwyLrT4dZc3bgZ1bKHlq4w96JWnBcW7FdDxcEc/i4TUnBsZ5RgbJddt7UI/R
axCOmlQJyKqtHHoMT4y9p6InZ3KUUrqJAJUCBRAq6MEy7LFLgVt3hU8BAcV7BACH
N1PI9Ru5rVVIl53M7zbTpbkgE0neQEWzgiuy7THHS3+Od/aEkZqWxL5GSz9qd1TP
TurvKcXXDtuF9frlWio3+z0MqNFRiU7ghex7zYBD/6sVrtRrJG+W0oekGyJ8/hJH
iYSfIQuuSHJ6zvBIoIjLN9mMlYk7d8yE91aZhVttookAlQIFECrpIRgnisK+iFyS
IQEBbiwEAI6YWLbWGcjUinUQ0D8Baz5te+nZG9eJSYRESrWCOBsdrP8NFj9TV3l3
FRxbSzWT1QGfaZx3u/3VIOpfnG04SrIG4RaEP/mn1PL19ShTQ1bVEQq7XKB+iXXK
kInBu3DMaRXAi8Hfq3ifTz/oa6I+GxiDS8CXDda7utC2cQ1WgrSGiQCVAgUQKtpD
RG1tOFJzS5pZAQHn0wP+LkupLVZYBbGPfXdkHaCxwRWEc5xBfIRO2SwpJZBBHclF
uu0OxxOuilc6bAiswbPHoMSP0MnOChOa+g0BFxhRjfKVXiXhP2Oo1lqAZ41r7E9h
4oYs4YYo7fjM1lZZtezWNKIibuW57lhdyvLMbDx6oxCP55AG7zTWRzL0DQnYsjOZ
AI0CKtHW8wAAAQQApMSslBzYEUQzIER/SRu3xXTdruTE0EQ4CZfa9ZNhVbTxe6jo
VfUzLTSno6iwzjEJgSeL/yPIukK3hH2whUXLD87dcR+dhSuuK7ans2owRo+cCfH3
zKTyMleHZEAVoTSOaDPVVUfUaDpukr0ujXMBa8DAIuoJrsKPiJ6a6GXD6cEABRe0
JkppbSBHcnVicywgVzhHUlQgPDE6MjM0LzFARklET05FVC5PUkc+tB9KaW0gR3J1
YnMgPDE6MjM0LzFAZmlkb25ldC5vcmc+tBNKaW0gR3J1YnMgPDE6MjM0LzE+iQCV
AgUQKtT1Lm1tOFJzS5pZAQEfUAQAjYXS5sbp/8ewlqx/TAa/S7n9DSgppoBEQrqp
4uFDInSWvyVz5VsGgbV7tP1Sxntvt9++xwfn2LdSPPDfBLElAiZ+Fd6yRwVd7wWV
bmFml0xFxHwhR6sfovEZ9Mr0RjdeefZhTuN3jWV7EQBHxyFlUQehf7jG104Tn45S
v0x7CIu0FkphbWVzIEMuIEdydWJzIDxXOEdSVD6ZAI0CKtW12AAAAQQArC5Odv3q
YspAvcmybjWopLbXQJ2EINYd3xiTEnKqKkdyytTIDVIFdmd7sbaaAz9fuGZ4Gg66
Fp+Y3PeVYizkiGIMqpxqcXaLbAaO2A+ZCpmYjbB6s9ZzqcjHUsPF1gg7v1LlDPDG
VA1eNxNqcjpAW1PAfN+mL1UhH8u5b+eWBQEABRG0JVBhdWwgU2NoZW5ja2UgPDE6
MTM1LzM0MEBmaWRvbmV0Lm9yZz6JAJUCBRAq1k5AbW04UnNLmlkBAS6nA/9BMkQ9
xoehzuOVyvBRqU7dIDiGR2TKp9q+XTe5tflTqfAhGDJeiUrxVt+FsflXJTQgHmu6
RLXNLyVdZv7N5EyfrQ+SRyxpmPLjsWWCk9CBQ9N0yvGOOgXJHJ/fNDRlW6Ce67qS
0czMyhVe5clvBnGg0dOWddUWOvNYN/u+9G3wxJkAjQIq0f0bAAABBADgjzogl/b8
dE3nct9bIGDrHyLFXMVvcVfK5DUsKvNrah9aGjMF2fPxu5Lujk6btTynY0IfAHuz
z/7i7UMfDhLD8YBHBJJNJ28C2TogiIS9jZg+AOWtUvUA+yJ3s1r9CAWgXWFihTYW
mu6f9FWBq3WnSKYqre6djqPZrd7oItiG4QAFEbQhVG9tIEFsbXkgPHRvbWFAc2Fp
bC5sYWJzLnRlay5jb20+mQCNAirQwOsAAAEEAPELC7P7vLHK5hz9urWhk9BJ+2i9
U1Yzzm6MKM/SI+UAVcXsYTP5g9kGJLUpLVq7KxalB1Rqbvg9FjjIaoiQ+ze7JIPC
5X+e0uU43iLMHkgz2mCg56p9hpgkDxwM3R+cHQ1cr2qrSJb8sClbYtknbgecNM0J
MusvUNwtSKqN9fslAAURtExNYXJpYW5uZSBDb3dsZXkgPDE6Mzc3LzNAZmlkb25l
dC5vcmcsIG0ubG92ZUBiaXgsIDcxMzMwLjI3MjFAY29tcHVzZXJ2ZS5jb20+iQCV
AgUQKtEZf21tOFJzS5pZAQHMqAP9EKg/17mW/gi0eWiUT/PpY+R+jBi0VtXAdq3H
Zo+VAFEyARt/fqiOuotiC7OFtnsuTPVtarOSxRpz/5bWdIr7AGIdbnwD2dmZwvqW
DBjvPDzQK1MwPPDpyqRtlEdU9LpwFkn9rVy77KShivrp4xHTVu4RjQUZ8EE58ilD
yhDolZSJAJUCBRAq0MaYednIlhgdxdUBAaqkA/4gm475FKoXXM9X0/1KH7HRqAiu
+VnrfvljT6GJt8c0BGtVsELLAGODAWCuzmP21IWlRznGvipnFXPoTrfi9bkjBijC
KmdhB/atLi9FB+YO2B3PWtwmUnWbIa7CQO9vxe4t8jYbyDiICAv72dLJXTHgMxPJ
AuFIO0ECqScYfb3ol5kAjQIq0LpgAAABBACUmiHr4bN1FBXm/zO/6Yt1bpyZrbcx
Lv/0pFk7/FkaPghdXXyjMZWSnosbw/2dVMMv3R1vJB1mWGl6W+tOkqjeqteOAE5C
f/iZHTGE4doS0pGdF8wa6e+mPFRZa/lV+3D9Rh0qDqoAlc0FShvd3aGUEI7eiIB7
cGF52ciWGB3F1QAFEbQ9V2VzIENvd2xleSA8MTozNzcvMTQsIDcxNDQxLjMxNTRA
Y29tcHVzZXJ2ZS5jb20sIEJpeDp3Y293bGV5PokAlQIFECrQx1HcLUiqjfX7JQEB
EoAD/0YzuJ4LMxKY3CunHyOHmGbAcOEXcG6jqH3GarymZgisy1s1OZB5V5ak4Czr
GCj7Yj8k35KDjp+IcQHDM1JpUDUKB5p1iLblWOWmIa0Zb7SgS4gYDY042knkleCY
pP39mrBC91SSFrGIWjM+wB9J1Izs8N5bWe0EEJonplR701/omQBtAirXWtcAAAED
ALKH2cKuVzOuSo2NTQVwNtiysY+7piD8FZxzjvDGgOYGVJMagPP3ohPmlKVwmky6
ljqtDVaGKDNBmWQlYy4KINpcPI801PtTnqzvLGa3aVs1hMX7mt218hn/G1O2n+md
CQAFEbQ5RGF2aWQgUG93ZXJzIChkdHApIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUu
ejEuZmlkb25ldC5vcmc+mQBNAirXO6sAAAECANunzqcH3SLKWFweZ3BAUXO3OuAI
SoBxocBtjmgsvndahwdXFGkQzSPgf6uWt3HIksD0a6sKPOrQjUXODZuyxIMABRG0
OERhdmlkIFRyb3kgUG93ZXJzIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUuejEuZmlk
b25ldC5vcmc+mQBNAirXWbAAAAECAKOREYOarMoniJ492Q11sfFe5jNAwqb7p5Uy
UCPJmcWXZ4mlHIWkmhqOXUM4VArnYKVIrddBDbkaEVBAW2UrY20ABRO0I0NodWNr
IEhheW5lcyA8MTozMDgvNjBARklET05FVC5PUkc+mQCNAirUKygAAAEEALVQCans
Isa6a+WfQiSOZDko678W7O4A/A7iUmJszodnQD+FVy+L2mcsL9pAjNwhAlHsBb35
FOVyD9XasQoyVFUZUrF7n6M5RruGGMrs5Pv2m1tVzkeZcSTWyPS7ovLQXRltBuS9
QbdZu5j8CzMM6g6GvvbqrK01TG5mb1FL1TGDAAURiQCVAgUgKtoRmW5mb1FL1TGD
AQFOnwP+MD6LDlj4EPvT9r9ZsLMy/pYQxMa++JMnAc2Qx+cs+rw8lHU3luXbeLwk
JZ2prh3YIdjHc682JGkUkFBSAWemsrAa387CNKU0K7Rsha9qCCXygswqUy1UjOIq
cGwB7uP7DR6nM+hklibbMl5acEpmihCEQkjUilcfA0GdWb5yGna0C0ppbSBDYW5u
ZWxsiQCVAgUQKt3s7x/LuW/nlgUBAQFOKQQAge7txev1ekLCmnBNuMcSI/r5uLJS
vhocppOnvR3MeWXaFsfLw5flwIhiWk/JGiXZ9a28FSdoZZrdDsMsZCSrbqmv0YWx
OGV9ojvy8UQkwdNNpJvUe8PJ6jPrHAeNheB0aWC3y5B1QFmK2efUNg9vgklVVv+E
FDEC2NJXpp27VpKZAI0CKtCnhQAAAQQAu9vnkZyc27CIVPYL1xZE3Xb+PE0GNLUK
AqPcWvWPKHGWmnpo0OLmam9R7tKYHEy3c9HzORS/WTjZyDSi5D/p3gB4YWNQlSwv
9cIuDaOFwlL6Fvpq1ndIDua2QhE4tfOuv6EDbZeVrbbDInJqfveeQf8uSy+epY9G
lrv0AJ2yUt8ABRG0R1JpZGRsZSwgTWljaGFlbCBILiAgPG1pa2UucmlkZGxlQGlu
bnMub21haHVnLm9yZyAgMToyODUvMjdAZmlkb25ldC5vcmc+iQCVAgUQKtRt1kq2
SryVeKUXAQEONQQAyiiv9L0KkmUXzWePJogB6zO4MDMZi0M53KhwuB9HYqN3Mea+
H67ZiC7W++Uv0WeXUxoZHMo/dBeGYuUvNBrz+y4EjjAK88PFsm0Fpm1okeeQ1Oic
0hBfCr190XvOVgsvJnlex8byyfWher46bXwmqamTxwDdqdABXiCSEUW9MK2ZAI0C
Kqw2TAAAAQQAwpYznabkRaLShwri7VwLY8/IdPq1q+T08LdMHlcFgN6B/d2yV1Gm
eMmPWv5o7TwUU75AsQj3C0Gq9/U88/mItfuwPa4hWUkfXgw+3JW2Ob1kpvwky0Jb
vjTjkGC0cEL3JDdXu9c1XmMzp0TahycfgAj+kEWsYsk8qBMDr1ghTDcABRG0Jkhh
bCBGaW5uZXkgPDc0MDc2LjEwNDFAY29tcHVzZXJ2ZS5jb20+iQCVAgUQKq4zVOJ1
3g7/Z/cLAQHKtQP/e6hXbL4W6Jyut3agNrCA7D0SNzHoT5PL09U+oq9+UuzTNjIZ
94VVKAFtNIM/df3U3cXryfJ2X0n1UDpBEIZ6UczVxlG6QInQBhsph+nBQ3TGMQYe
wOt3aBPmJaUHe8Fm+L7phuzitKr6DJnNWbX/6hGsx6ffZ/PavQIuBS0eiTaZAD0C
KtZoswAAAQGAyUkguJ/Gtcfx+QnAlt5IdcBjVD38DM/JsZXLQPH+rvQWvd0qEzpe
hISBrDYTPOfZAAURtBZNYXJjIGRlIEdyb290IChjYXN1YWwptCNNYXJjIGRlIEdy
b290IDxtYXJjQGtnNmtmLmFtcHIub3JnPpkAjQIq1lDiAAABBADMGAE/s57s7web
wHZuIwfhCYinZ6ANRL8S/lmuC+FvUNp6dXIG5ahLx/Lje5w78vB1+eizA7uhc5Vk
R5Taivc+F4EOwWCrnrzYXMch0BOfzcZSrSOaEhINdZiy1OZ0tBGfRFMBIUFjIWCO
T4rb8U1TPbXCon6lvwTMhuHAFEQqPwAFEbQiU3RldmUgQ2xpZmZvcmQgPDE6MTI1
LzIwOUBmaWRvbmV0PokAlQIFECsDlf6+Xqpu25EANwEBIxED/22n8dscoVytUdSj
O6MBG2tr/Cg0vBkNAuzx+b811IpDb82d9qei4znX+BBXZvaXKO2RCyZ8ECdL3Ejg
DvoZ9riZYdumLaWyuzjCXqBIbMPyrHwo/DN0NVxFAUr066c2fdz0uXyoflYp4pCt
FSAipfQEdPN/cn0JRf5qXbi344LmiQCVAgUQKuSfsm1tOFJzS5pZAQGTAgP+IYD0
obZ4NDWk3OWIfcI6673UhHUdK786ojzhqeb35qUozy7Go3fpLqg/qMVl6miIjSRh
oad4GGGl5N5XlzJ9tdSBa9vLxK4J0bD2eZoZhFIB4ERKoHQtyW/4j3l0mEpbLBFO
4tCSV+telId5XyH58jN+GYQHZB/efNivRD5EH3KJAHUCBRAq11yc/xtTtp/pnQkB
AfRXAwCa0gG1V0oAC0znEWWH0979WL1M04/5+S0qJttcLVgiByANgPxCHOb/zVZX
w7QISTZ6tUcKAckL7Lz8GGHJFn3tn/S6OF6sBYyaOJJpNemdMbliSyRgfZ9+Hk+o
6Jg5gMyZAE0CKtXavQAAAQH+LvwF92SYQioq3YSF2UUAlzjisHdkzMKF7PnNVwH2
NGlTPWgxjYzYae5wZFRy8xK9l4X9qoJUge6h0N+rIZhhOQAFEbQvU2VjcmV0X1Nx
dWlycmVsIDxTZWNyZXRfU3F1aXJyZWxAVHJlZWhvdXNlLkNPTT6ZAD0CKtTNtQAA
AQF+MLenkI4RQwnfHOuriwkJNpTkyC/ML3i2nzLHEEl4pQajvHGAxKEEKchmn7GU
WLLFAAUTtBhQZXRlciBNIFNoaXBsZXkgKGNhc3VhbCm0JlBldGVyIE0gU2hpcGxl
eSA8c2hpcGxleUBiZXJrZWxleS5lZHU+mQCNAirRDBIAAAEEANSxRNwbmOKiEs2J
zwsBfn3KRA3y8X0JScH8FCrlq7tKGFVgp8C4bO2UCQ+TT8p1V5cbsB7594ykIAdi
9lCefxXP0j/Id3NBV6Q1CQ4bYnFPcLalBZ6zlGIB9TIdwKxeglqlUxVcPBGpv8YZ
OYJJuOxl6x7GD20IzJ1vNJwmRP/PAAURtClNYXJjb3MgUi4gRGVsbGEgPG1hcmNv
c0B6aXBweS5zb25vbWEuZWR1PokAVQIFECreDGbNP+0u9SVxFwEBXToB/i/9KOQm
rGOZLBDvVOeBOxIkQRyFdFsZ2AdzbZ5m6WcjUFerZj4gaklHUiRAM71qJrXuzH9t
aLppjrSVEp7g3NmZAI0CKrCDXQAAAQQAxU0wjvrqWN65bTXGpcphhXmWYM+9v7p0
JArebWIFB1qfSeimbfmPUMhGndQlmiAB7l6KaxCDVMAsOFOrfXQ5mz34voH8fF5f
f7gFp0gNp3iD7EiW9oVjVS3+Ex1k2TDS3M1k51Q+I7iNgjKKtF4BSIwKbqNfORNE
hOPv+/HFa08ABRG0M1J1c3NlbGwgRS4gV2hpdGFrZXIgPHdoaXRha2VyQGV0ZXJu
aXR5LmRlbW9uLmNvLnVrPpkATQIqu2UwAAABAgDAKv0Wo7mBFugi6yOIABpejWBv
96td5+bZzO8q9abOboBFmA6vFxYKvqhRV3l0URshsk8VrPc4mRj8NL7MGZAJAAUT
tCpCcmFkIEMuIE1jQ2FydHkgPGY2MTcubjEyNS56MS5maWRvbmV0Lm9yZz6ZAI0C
KraubwAAAQQAy5m8cJl3gIaF0Nx9V8mPHof9wHlQUnQWGTNqW4NnfsUruef0FeFw
QJUDajdNBY+MiH/vzuzaveAVIRFojgeUVpeNa8gn/cFiCQoLFtKbM308isD9A+81
fK/+sTZcEQWhH2LFbPxb0kQSSTCNK5HejX9bzSIz+wayU4mYQzmyV98ABRG0KlNo
YXduIEsuIFF1aW5uIDxmNzU1MC5uMTA2LnoxQGZpZG9uZXQub3JnPokAlQIFECrQ
19ltbThSc0uaWQEBrHMD/0a8m9ZX9jVREbX3RMDV6knJQbZFGu2KL9syqAFcofqQ
RWEzOcnQz7+G4XjbXedy1kTTxHKcIGyClXFD7LqgEL8bHD1i5yLU8AHTff41kBtz
twlo7GCZlfs9Lqj3qzX9GGXZEeWEOxwl30qBfXXWEsUkFrK84Uh/L0CKa3vpYW6W
mQCNAirNLf4AAAEEALMyyNvisb1TJVHyhgvta9npDwFoJIOpJqrv8cr5OpeCOhkT
hxhWD/dYmSZEzxlu47BUDj1KyDRemP0og0Lp2xsxJLmAiGWKd4zYlHqKhXAgJJuz
KWK8O6BOfZUbFYwCCKGonbPtPPdUPp5KCluSpLBdT2BQsk0okW1tOFJzS5pZAAUR
tChDaHJpc3RvcGhlciBCYWtlciA8MTozNzQvMTRAZmlkb25ldC5vcmc+iQCVAgUQ
KtDGbNwtSKqN9fslAQH8/gP7B7p7z5BUmfJhZJYdMoSRSAZkVP3LvvpCZGZDdGye
6lxj+WF2X2rCXohAd2jnQJdGCFE+6Q8zP6tTbTikoIksQ0hbP5xFIfKp3Lyeyy06
Mzh2CipYHyHRByGU1q+bQsCYotMIqAntaWcYXEdj6eB6pUxselvFH9RQAV/cPJgu
JOmJAJUCBRAq0LwEednIlhgdxdUBAWo3A/9yS1zOQuRHCVx77hzuvC+fue+64jmA
9WWw50Yumq2cnpwSA49iDMepby1CtN5x9RObVNO1UqSfAQ/lgPEJgNyOW8zfWf9L
t+vgF5BL+5q0LEOqGj/yQUVs5bhzp961XeVqDSlE7FdaUIZghgn13NFWJK++VLhQ
IeY9s3CZR1cbWIkAlQIFECrNY8oYV+Tdsba4IwEBIo4D/jWI/JWxluKBsTTjdNBz
Y79dMx16rLLs/o7t/AT9D6HlC2GXSl3VJ47eSvGqNpcuCNnTukixv/7qeFTxSR8I
S4V1b1gTu5w4hgfZNKcBK+/RYDnvFs2W49Vu6LyAFG2uqmgV32ojKc9uELG7Cyo4
3u2KfDBEDKCJ0TK8biVVV4SriQCVAgUQKs03K21tOFJzS5pZAQHQAAQAgT0DzRqH
vx3lPvdmYe8eW5eMxgGL3o3TuLH3/A8ZrmagSgCtXVQvw5n86xVdMAsfnw+njybo
D3oPPWsf656XomW703JFE1XPDiRe/l1gLz+i7sruG+AHrW6ADG1Ls/POMWui130h
QN39uSY/3iVnRd4WQTfA+Uw3UmWSi3mTZfSZAI0CKsZlkQAAAQQAvpRxOtg8oVxC
NOzW9NvEao3W3da8XbH03xms98grBOF88+mlReQKXobPRj+R+71ZuEOiIGcwoiu9
dO2xb6HR/YubwS31Gu0wFH0b4I2kg+z6Uk1n2Ozysi6Nfu5qcG39Ur9nSHB0ivMn
xgERp9XoomDeUeZ+62d3GFfk3bG2uCMABRG0NEdLIFBhY2UgIFsxOjM3NC8yNiA8
Z2twYWNlQGYyNi5uMzc0LnoxLmZpZG9uZXQub3JnPl2JAFUCBRAqyEWZzT/tLvUl
cRcBAVysAf9AzA28lwwpOWjQew7c7S2dCf1pZrsbVjvIH/NWMATysrUWE5u2Ptk9
tJYsOijH7cSy9uDIDXKcXHhSCJVWShxpiQCVAgUQKs3JC21tOFJzS5pZAQHyJAQA
lMgaSBlNourM5deAGSrgqbinr/T/0nNKCfPpZ3SwKe27No+NEbFmHCpPPjrNSVJo
GDN1p8ePSnZdvuqb94cJCGwkdHBWd2c0xAjU4zUY7G+ddogmXfE/7mGdWtXL7Xtg
a0vpDZdQ2AubKKCRntaXGNzrqP/5e6csUAhUHd5VLLOZAI0CKrDAUAAAAQQAtjl8
7QTiBTb4jkruf5IgK7Ig01Saj/PZQu8ruZTbkJbXqkb9RN7q2bbG8RLYjJxcEzCR
6a9atG7NNteSuQf4/yu52MxmqIF0BikLD3vqtxMSLKYQpGdXjjAS3T4NhBj4Z7QS
3cijYnWpiMmhHb0egsVV1S3hOnIIZitHZ+yaIMEABRG0K0FyamVuIEcuIExlbnR6
IChMRU5UWiBTT0ZUV0FSRS1ERVZFTE9QTUVOVCmZAI0CKm3yLAAAAQQAsYqAtuUR
AJ9xkSJD6MEWfDmDQH6jXoYw+yxgEojttaCMZsEOqeRCgwZqA0mlwbm1fZsqkl16
CLTVKnbZA4yllt2u/8pdFYen8mOs0sBken0H6eWixtGs8uEZlkD86DJToPYawacw
NxNpw8PjfCjWD5FSkO/5SMyv4nXeDv9n9wsABRG0LFBoaWxpcCBSLiBaaW1tZXJt
YW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+iQCUAgUQKs04AW1tOFJzS5pZAQEr
qQP4zrYEvXhV77y90m2Vew8ZbDD/pxSpVWwgM16uU7CBVlAvMqTs/24qT3qJ4Pcl
2K6P1gCVj0Y+m4PFO07UYEm5UX00BYEZxiFFT4w5CO/4BJfrIu3oIdaadSYxdBz1
uJYZouoE+kEvd35tIppVPXuGLRXdeojXuw/VOGUYgV9aU4kAlQIFECpvUjT0ygCB
jeci2QEBOfsEAL90+6LOAaROuDLyKKvcG8yTSg/HbkRUrpYsX8ya2O9NRvr2sLx1
zehE5/nRUKI1Tk2pzp5J94qaS50mjlW+a7Kf5tMz9JVpDPeU8Y3k7+Pnb+DG4lhX
BkyUvV3AiqK3x89ZW/jRozIHM+JdT7gyUQ3Vtf2P/4zTvlHyocusmGIgmQCNAips
wZkAAAEEAMrcqvIwyKcvxWjFbUIq7/hhzWTrpeThdIxJl7T6P1sX9U6axBhSa1qE
8LxwzTZ7/fhqaUlcZbrho5WODDqge325k7c2DCiIGxG+awndQR7a6X28/U05aQXQ
iMnS+IgDOLo6gCtGUFoLDoUob5AuljqHlOrQovmoIPTKAIGN5yLZAAURtCdCcmFu
a28gTGFua2VzdGVyICA8bGFua2VzdGVAZndpLnV2YS5ubD6JAJUCBRAqbfKQ4nXe
Dv9n9wsBAcIXA/9w7xBNQn8sTkmfBy6S6tFk7GFGHvQA/9eryxHlqjDDhBKQeSJJ
GvPHmNQQ32CnVuv6M54qxT9iusopMv1RFS4ZXTB9u5KV4ajBGvkGfMsHLYgiAEcd
UwndShAm6St/zRoJzQ3ae0mAFk9MYJKYcMuJYL3wCZjrrI5YNrrhSO52w5kAjQIq
ezKiAAABBADWbUO71XAVqN9dlef3kGRtlsSA9gnOkoRCzVlo4hFvO792Ie/Y1p/c
5pz2YAyU+9C0beZHVWHwofAdUmdpF3iz2q+4viODLN2UbD2E7hoPjm3HLLjgiRCK
y7lBjtEofLm0TU2mSuAZOR4zKaNcCRcRcSCYtAiJZA/6EarpnZl9RwAFEbQlUGV0
ZXIgR3V0bWFubiA8cGd1dDFAY3MuYXVrdW5pLmFjLm56PokAlQIFECqkeZfidd4O
/2f3CwEBrsYD/AqgSbc7d3qYO5Gww2MxZX4gA04nzHbyx3XnX6xWUOU6w+Rx/X/0
0hP42og+P3Rf+pBg0y4KiIe7hY2TOb6neh3qpcpxkHQKtUkRQd6zYFNRuYoRNTge
usTiiAv0cL6RYaZFWt44RzbOr3tJZrz3uPHLz2nvDvec4zPHvMoWyeVFmQBNAiqK
PnYAAAECAM4DUPnxdjb43Il+yDkRUO8TgzOW/hjTs1/blllrVe8HDlABqHZMib0a
NFhKRFYjvsNS3xk34N65vtlI/HoTNvUABRG0IUhhcnJ5IEJ1c2ggPEhhcnJ5QGNh
c3RsZS5yaWdhLmx2PokAlQIFECqmFtb0ygCBjeci2QEBqVwD/A/8vnke2KFNyFLT
OdYhiAZlbpPuo621TIYWVxPJ+D+TVkELdn7HWmDpDGQ8l/7XmuDEBrGjFiQj1Mv6
7+rnEqhA4ufKyKS57GuSZ90G99iLLimCiA9ytQyRz8Wi8GUzh2lpv7/478NvxEgy
a3nVM6LwkXodv4OYPVxUnLoSNFGFmQBNAiqc8q0AAAEB/i6Q/XxMaNqWP1tY4D8v
Hr5KiwFz1XvE9F5ltPVPeW2I0EORg6u7xSlreXo9OvRd0BbF+UdOAjH7Pwvhv9xi
BCMABRG0IkplYW4tbG91cCBHYWlsbHkgPGpsb3VwQGNob3J1cy5mcj6JAJUCBRAq
p3Bp9MoAgY3nItkBAegyA/sEwCWN7IU1T0NVNkcOcqe+lCn8P42UfX1RUKqCfErq
T51BAPnSIz0naWFQII8ZE41FQQ6iuKnbfKpmIi4VelzcjzsEwdw15cdnyV8O9FXQ
25ysMe1C6LkodMU20XMjH7744n0NG15PWbNcmwNOQ2119tw+u9rRuuC6PFWFvX0w
VZkATQIqxyFfAAABAgDhOocrwWVLJVToItdrune/+sjCF1+GiiEXH1d8Gv8rB5fr
pXeGoAtWFvmIpmHgPv21zgcR/2Pykc0/7S71JXEXAAURtDFUb20gSmVubmluZ3Mg
PHRvbWpAZmlkb3N3LmZpZG9uZXQub3JnLCAxOjEyNS8xMTE+iQBVAgUQKw7lYq+0
ixu9+x8tAQE8EQH/ekB1naYVMjS32UNxfoWzLs8Scm2mAOhTNPTdaXrFgiaLoP9Q
bxLt7gS6JlU28uRU3PrzxleFl9ZlBaaoyqRdzIkAVQIFECsO3ggN91aF3b4N1QEB
w5UB/3qPWHWzh9ktog9168XSPLVyKSDz5RCKfRc1Cnf2+iUUrG+kh9IFIMrOB14r
AMdhOJR105MmsAzlfaYdXkwjIr+JAFUCBRArDtXmThgGN4+JhjEBAXbbAf9U8Wpa
el26ikgjnHGwstsfaTUk59Lmu9K4q+hxTS9BovZnVq+Bbkmbx6dRtFhh8qR6bkT+
hAE8BrJ4BB8ZBaU9iQBVAgUQKw5c7VQDRxQAIuUtAQHk4QH7BmaPxtehZJOyQYjV
aRyCtMkXdcTBk7tS8FdGK310DMCqr61mZQrVli7RmzAq8pQSJ3GjhvbYum3TEnl2
8P79GIkAlQIFECsOzyWh9UOl6XLwEQEBYCwEAJzTGLfan9mbFzNx1yubrHIofOdT
LSaxyPHKd8eiYgWheIOnTTWS0en6JOSWsGfp83lTBBH5USCIxOtf+WzK0SbydKhT
xbHPouryo6d1Ycmgty4rKwluEQjuytT5mz0nrlHXgrRo15WeumFNC9oPoLq/Tiu1
StGfqk/gwvntHQQBiQBVAgUQKw7JTIxutC9MEx9XAQG/kgH7Bh1HrIvqVgAWn2n0
3fpqOZTZKKQ0yJyWAtwn0fOaO6Yb7ze83IlqnylArrYB4MK/sgY09M9k7py4lAqg
Xu3wdIkAlQIFECsOvwqtUkpRhRl/tQEBZPYD/j/kPMH9agh0dBP7oKUuFgAAt5Qo
Wlu7KO7YHeRyDzAbwIncksQkIy+ZKA+X8EYJVNXESesdBile0/guom4d78FWQwJK
mhz4JsNlfIkaz8pKrClSrmvLUh4cLThM8O8139slsQXCHoK9xoiDwOzwu/wdeD7d
L9OFdWXkEvHQmPk3iQCVAgUQKv2NMuo6/NNxlGvfAQGuLgP9FaHSxeXSFv2P92ku
EBCBg5Vxi044apXRITH3qaGNYMTlZ4uVrGrP3ycl/yQEwr1SJsTPGGEmXC250586
Gd59ZwAE0YS6I3HywaO7I/T/2DoJ6aN6op9r9MjfmATr0qCtAOh3iwLWH0249Wou
n2pSVqlV6u9uwKW7U43M9Wan/MqJAJUCBRAq0OE2bW04UnNLmlkBAZGsA/49Wsio
wQ96ICa38r2CNbbFY5VBqvlfu/74L/wGohiPyaaYZ129BrT3y17kLU7K6cxMrRe0
XPuQi9wMmF8rOan6t0jpN8ZRG9qyaKtEUA/E9336UlwhDIiceJEMBEW5vXEY5D5D
Wd1expfV/Q73e/P+SNdjRKgLwhRFjQ4WE8XWlokAlQIFECrLhGIYV+Tdsba4IwEB
of4D/1LcLzjP0Ir80uXVNzPPaHEbpHgLjWnA89Hj0tfXA0Np95zVHKENQ9U/fuRz
5G27rHFmy+wCTX2zsrDBgTlKn4hGwOTz5CDfnjnB8NVQ19Xt9KF/tlbe1ljbJtmn
cY/dPMfwkWlCPFHLXPWw3IiFlJo1hRvxrAM364ya3zNTVJsPmQCNAir9fucAAAEE
AMXg/uYJqIqJ8pr9B6QTh7NOgqSMpwJK2v2QfZ4Ur4jeCiz1vJoXsxlOwsLEqRJZ
wT+8/atljTbVWepJZbgqzCJK2J5c0+p32mjUSQVZvF9CU4gPbCehUgoToHmheGQ+
kkzimXLi39XzqoyT3ORZ07cQT+1DgEBDVa1SSlGFGX+1AAURtB1Kb2huIEdpbG1v
cmUgPGdudUBjeWdudXMuY29tPokAVQIFECsO9LdUA0cUACLlLQEB+PEB/2+N0xYQ
Sfqepii8vJYDtAevhzkQyupPuNmhPUGi8148Dx7IckqX3qv9ZyWKdFBuWQqYAJoG
7Gnd+wEn6SVkztOJAFUCBRArDuRKr7SLG737Hy0BAbOpAgCWUETOCKU9fmj4n1Y7
WbnbSMT6w2ua8eSGIy7olVdL7r+LG82ZTOh3PhYkdZXBobwumoMzzmlJzbu+lQh7
7L+biQBVAgUQKw7dvg33VoXdvg3VAQFyKAH+KCRi9cjMCVAldkdTNW+gbXXkk0r8
55hQ4ewrP5ELRqwyvYJZDIKoxFOC61LaDNg9Xzu18jNFGmRpsCMC/LX9eIkAVQIF
ECsO1LpOGAY3j4mGMQEBdj8CAMI7zD5bBXZtZ7mzikXo4/c5E6J6Jgyjwm7+FjMe
zWiEEg2QWWTsqeyBCRTqE9xcG6YGJiJd/sSf0lBWM1RU9IiJAJUCBRArDs4v6wCT
6wJFxDUBAXLbA/9uz6/Ek1MH0iB2bgHELKBYH8mL0v1/WtPp13XKjFkLRkUepcsJ
FqQUN5n9EVw7PxLPMkaQMsgC2o+JrLuGqAIkQd73kucr3iKHfB25ErRx0dMLrpQF
A13/5P16VJNXBTW3juNl6oMq5z7Up7jfTB+RJoeUV/92DF+Qi20itrvWs4kAVQIF
ECsOyK+MbrQvTBMfVwEBlE0CAMM6o1rAcb2UntVueGoBjGRYUApxhdSZD1LbQV21
B/jzbYtEDQ/cbf/b3kMv/rgZWEJQyoVL62xnTd0TXr8xwr6JAJUCBRArDsUxofVD
pely8BEBAWg6A/9h8kODUzDaASOq0fdz386YKnPjId7hik1Nol66tMS0J2PdRLJr
VuNyuYDwbH9iREeovQ4mow6/es7zY+Nx8/c6yNXMHQlj/OKJNJ9KrPfENkLMzd8J
zkqUFVnqdEHpmZYxrysz9y72br7KTLmzAnumCERSWCNI/G8+SBMh4q+kbokAVQIF
ECsOvpfNP+0u9SVxFwEBs44B/3UqcFw085h9KPigF39nI9U7MxhwdzsbLEdRL0OW
XP4TQt6azApOhfKUvFHTo7dAoP3aQPVKirfA+zNIFIFC7ASJAJUCBRAq/YCy6jr8
03GUa98BATuWA/9KG5CXCoDPpthcfsbA2eYIhi7GduqSkFi2//ibeH5HTqtEUrlk
PGPQuxSmMuQSaUhAGQrYpVMSpTdcv3BWf2jAUgMgoXwHkCIBqOaG0Gwjijnm8+ho
x6v+9zr5KvylqreCWTWdFuxP379+gFEsN8t+gXIH9GiXHjeul4jnD+HgNw==
=MUTM
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Fri, 27 Nov 92 20:28:30 PST
To: cypherpunks@toad.com
Subject: Re: Electronic Banking
Message-ID: <9211280427.AA21844@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



"Using the net, the 'banker' could easily be 'offshore' and not 
 subject to US law in these matters."

Feds busted some folks doing just this with modems in Puerto Rico,
I think it was, within the past year ... heard it on NPR, maybe it
was BBC or CBC ...


-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

                    Klein flask for rent. Inquire within.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Fri, 27 Nov 92 20:42:26 PST
To: cypherpunks@toad.com
Subject: Re:  PGP on local machine (was Re: MacPGP)
Message-ID: <9211280441.AA21906@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



" ... some kind of hardware device which isolates the line and all that."

I believe part of the MIDI specification includes explicit decoupling of
each device from the network via optical coupling. ( Ref: _MIDI systems
and control_, Francis Rumsey ... "The interface incorporates an opto-iso-
-lator between the MIDI IN  and the device's microprocessor system. This
is to assure that there is no direct electrical link between devices ..." )

Anyhow, such a component is commercially - and easily - available.

-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

                    Klein flask for rent. Inquire within.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: norm@xanadu.com (Norm Hardy)
Date: Fri, 27 Nov 92 21:35:51 PST
To: cypherpunks@toad.com
Subject: PGP with license
Message-ID: <9211280507.AA11162@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


This was originally addressed to Phillip Zimmermann.
Thank you for writting PGP. I have not run it on my Mac yet because my version
of Stuffit is 2.0 which deems the PGP.sit file to advanced. I resist
the incentives of compression program authors to produce frequent incompatible
updates which cost money and delay for little apparent advantage.
Compact pro is a shareware program that produces self expanding archives
which presume no pre installed decompressor. It is available by ftp at
sumex-aim.stanford.edu
info-mac.util.compact-pro-133.hqx
You may forward this to whomever does the Mac version
or send me his email address.
 
What I really am writting you about is to suggest that if you wrote "another"
program compatible with PGP under a PFP license that I would pay at least $50
for it. I might pay more depending on my experience with the free version.
I would accept delivery by email.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Fri, 27 Nov 92 18:16:47 PST
To: karn@qualcomm.com (Phil Karn)
Subject: Re: More comments on dongles
In-Reply-To: <9211272352.AA09880@servo>
Message-ID: <9211280216.AA05139@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> I still disagree. Even if all the crypto operations were done in the
> dongle, it wouldn't be a "turnkey" device that could operate totally

Maybe not "totally" (there are no absolutes) but if well designed, it 
could come VERY close.

> automatically.  You'd still need a way for your host computer to turn
> it off and on, to select a public key for encryption or signature ...
> ...  I.e., you'd have to run special driver software on the host anyway.

The way I envision it, the host must NOT have the ability to turn it on
or off or do any of the other things you mentioned.  The assumption is
that you DON't trust the host.

All these commands to the dongle will be given through the keypad
and/or commands you type in from the terminal.

So if the host does not even need to know the dongle exists, it is
automatically independent of what type of computer, operating system,
communications program or terminal you are using.

> process. If I want to decrypt a file, I'd send the dongle the IDEA (or
> DES) key that had been encrypted with my public key. Once the dongle
> responds with the decrypted IDEA key, I can perform the actual IDEA
> decryption on my host computer with no further dongle interaction.

Again, you are trusting the host.  What if the decryption program on 
the host has been modified to quietly write the plaintext to a hidden 
file.  

> speed, not the speed of the port that's talking to the dongle.

Once the host decrypts the file (at a high speed, as you say), you want
to view the file, right?  That means the plaintext is transmitted from
the host to you.  Anywhere in the link (which could be a simple RS-232
connection, or a chain of network links, modem connections, etc.,
someone may be watching.  With my design, the decryption takes place at
the very last step, just before showing up on your screen.

> A palmtop ... would make a good platform for a prototype dongle.
> Most have serial ports (standard or optional)

I have thought of that too.  I would need one with two serial ports
though.  If you know of a good, cheap (can something have these two
properties simultaneously? :-) notebook computer with (option of?) two
serial ports, please let me know.

> Since it is a sensitive step, RSA key generation could also be done on
> the palmtop (although it would probably take hours) or it could be

Since that is not something you do every day, I think you can tolerate
it taking a while.  How long it takes also depends on how much security
you want (i.e. key length)

> main reason for using the dongle is to limit the trust you have to
> place in a borrowed PC (as opposed to protecting against your own home

That is just one of the reasons.  The others are convenience, lack of
trust in the host or the network, use of a terminal (which can't run any
software locally), use of various computers/terminals (at home, at work,
any other place you happen to be) use of an environment for which no PGP
implementation exists or on which you do not have the access to install 
any software, and I'm sure you (any of you) can think of other reasons
if you take some time.

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Fri, 27 Nov 92 22:00:11 PST
To: cypherpunks@toad.com
Subject: Re:  Mac PGP report and Rander progress
Message-ID: <9211280559.AA22444@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



"Has anyone given any thought to generating random numbers by counting
 particle emissions from a radioactive source?  This might be more
 reliably random than using purely electronic means."

The Exploratorium has a display - a large set of charged plates by which
one can see spark trails elicited by high-energy particles as they pass
through the array - which has often intrigued me as a source of noise ...
what is more unpredictable and harder to spoof than a cosmic ray detector ?
Especially if you use not only the timing of the particle's arrival, but
also its direction through the array of plates, as inputs to the random
number generator ...

Air pressure, temperature and other ambient factors in the environment
could also be used as sources for unpredictable inputs ( measuring very
small variations, IE, millions of a degree or some such ).


-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

                    Klein flask for rent. Inquire within.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Fri, 27 Nov 92 19:43:52 PST
To: karn@qualcomm.com (Phil Karn)
Subject: Re: More comments on dongles
In-Reply-To: <9211280249.AA10136@servo>
Message-ID: <9211280343.AA07573@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


I think we are using different terminologies, maybe even different
paradigms of how e-mail and other internet functions are accessed
by people.

In my terminology, "host" is the remote multiuser computer that is
on the internet, and provides access to users via dial-up modems,
local RS-232 terminals, and PC-s running terminal emulation programs.

The host could also be a BBS system (as in the case of FidoNet) which
provides mail forwarding for you.  It could be an on-line service
such as GENIE or Compu$erve.

Local equipment is the terminal, or Pc or Mac or whatever, that you 
use to connect to the host.  It could also be the laptop that you
connect to a cellular modem and connect to the host while mobile.

You could always use the same local equipment.  Or you may use different
types at different times (a terminal at work, a PC connected through
a modem from home, a firend's Mac, a borrowed laptop using a
cellular modem, etc).

The connection could be direct, as in the case of a terminal or
a direct dial-up by modem.

Or the connection could go through multiple channels.  For example
you could dial up a TYMNET POP, and then connect to your host.  Or,
you could call up a terminal server, log in to a guest account, and
then telnet or rlogin to your host.

In this scheme, the dongle sits right between the local equipment and
the connection.

> >The way I envision it, the host must NOT have the ability to turn it on
> >or off or do any of the other things you mentioned.  The assumption is
> >that you DON't trust the host.
> 
> If you don't trust the host, then why are you running your plaintext
> through it?

In view of what I have said above, I am NOT running the plaintext through
the host.  I am running it through local equipment, which I may or may
not trust.  The host (being the multiuser system, administered by 
someone else) is always less trustworthy.  It is directly on the network/
It could be immediately transmitting everything you type to NSA for all
you know.

> ...  if the worst that can happen is that the only slightly sensitive
> plaintext I'm working on at the moment is compromised. ...
> But I would probably NOT be willing to trust the same PC with my
> secret key, because it would compromise EVERYTHING I have ever ...
> Do you understand the distinction here?

Yes, I certainly do.  That is the reason for having a portable trusted
device in the first place.  But, in this sense our two approaches (my
smart dongle that does all the crypto functions, and yours that only
stores the private key) are absolutely equivalent.  None of the two
exposes the private key in any way.

> >So if the host does not even need to know the dongle exists, it is
> >automatically independent of what type of computer, operating system,
> 
> I seriously doubt this will be practical, even with constant
> interaction with the dongle's keyboard. 

See my next post "STORY: scenario of use of Crypto-Dongle" for my
vision on how this would work.  Then, if you see any problems with
it, or suggestions for improvement, please let me know, so I can
improve it.

> to truly sensitive things, like typing in my pass phrase to decrypt my
> RSA secret key, or perhaps hitting a key to re-enable the device after

That is the kind of things I intend the keypad to be used for.

> Most palmtop keyboards are a real pain to use ...

The dongle will have a numeric keypad, somewhat like the touch-tone 
phone, with letters on the number keys, and a couple of extra keys
such as * and # for functions. 

> >Again, you are trusting the host.  What if the decryption program on 
> 
> As I said earlier, your "fully-functional dongle" fails to prevent

This misunderstanding is due to our differing use of the word "host". 
When you said the host would send the rsa-encrypted key to the dongle,
receive the decrypted session key, and then decrypt the file, I 
understood you as meaning that the remote multiuser machine is doing
all this.  

Now I see that you meant for the local equipment to perform the decryption.

The problem with this is that you are depending on every piece of local
equioment to have a copy of the decryption program, and every version
of that program compatible with your dongle's commands structure and
key format.  Or you'd have to carry a several disks with you, with a
version of your software for every platform you could encounter.

> >Once the host decrypts the file (at a high speed, as you say), you want
> >to view the file, right?  That means the plaintext is transmitted from
> >the host to you.  Anywhere in the link (which could be a simple RS-232

> Eh? The model I have is a local PC, possibly hacked, with a serial
> port connected to my personal dongle sitting right beside it.

In this case, you would have to save the encrypted message into a file
on the host, download it to your local machine, and then decrypt it
using the above approach.  This would be some amount of hassle, when 
compared to just using the mail reader software on the host.

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Fri, 27 Nov 92 22:48:18 PST
To: cypherpunks@toad.com
Subject: Classified info and other stuff.
Message-ID: <9211280644.AA24107@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


George Gleasin says:

>I'd like to ask we have a general agreement to not post things which may be
>classified.  No point giving the govt a good excuse to stop our R&D projects
>cold.  

I absolutly agree...As an ex-air force person,  they can get really nasty
if they want..


Oh,  By the way,   numerious complaints have been said about the way that
the Mac PGP was stuffed when posted onto "umich'.    I will be pushing for
releasing it stuffed with a self extracting archive instead.   I also had
problems and lost significant time acquiring the new stuffit in order to
extract it.

John D.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Fri, 27 Nov 92 20:17:26 PST
To: Tom.Jennings@f111.n125.z1.FIDONET.ORG (Tom Jennings)
Subject: Questionable Discussions (re: How far is too far?)
In-Reply-To: <3920.2B16E302@fidogate.FIDONET.ORG>
Message-ID: <9211280417.AA08200@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


>  U> myself getting a little uncomfortable with some of the 
>  U> more anarchistic ideas expounded in this and similar 

> I agree, even though I'm interested in uses of encryption other than
> privacy, implementation of privacy systems is a baseline to a lot of

Yes.  Once we have privacy, we can safely discuss all the other topics...


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Fri, 27 Nov 92 21:00:47 PST
To: gnu@toad.com  (John Gilmore)
Subject: Alternative to physically meeting
In-Reply-To: <9211280415.AA12997@toad.com>
Message-ID: <9211280500.AA08808@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> person identified in the name field".  Don't sign someone's key unless
> you are sure you can make that statement (like, they're standing in the
> same room with you and they verify that they key ID matches their real key).
> Don't sign a key that you received by email or over a modem; it might
> be from someone impersonating your friend (when they left their keyboard

Here's an alternative method if you know the person (know them well
enough to recognize the voice on the phone):

You transfer the key over a non-trusted channel such as electronic
mail..  Then both of you run a secure hash function (for example MD5)
on the key.  The result (128bits in the case of MD5) is then converted
to alphanumerics using something like base64.  In the case of 128bit
hash, you end up with 22 character verification code.

Then you call each other up on the phone, and spell out the 22 letters 
and verify they match what you independently computed.  If they do,
that means the key transferred over e-mail is correct.

This is of course susceptible to the kind of attack where someone stands
with a gun pointed at you and makes you give the wrong key, but that
attack can also be done if meeting in person.  I.e. someone tells you they
are going to kill you as soon as you step out of the room if you don't give
the compromised key.

But at least with this attack one of the persons knows they key is 
no good, and you will avoid using it for sensitive material.

Can you think of any other attack that this method is susceptible to?


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Sat, 28 Nov 92 00:27:13 PST
To: cypherpunks@toad.com
Subject: Re:  comments on Don's "Cypher Bank"
Message-ID: <9211280826.AA22989@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



> I will maintain a public list showing handles vs. Amount received,
> in collection, and in escrow.(Set Subject = "BANK" to get the list)

"You should not disclose someone's balance to anyone else, and certainly
 no[t] to the public.  Someone requesting their balance should send the
 request by any communications channel (anonymous mail, newsgroup, anything)
 and sign it with the private key corresponding to the public key used
 when making the deposit.  Then you should encrypt your reply (the account
 balance & any other info) using the public key, and send it back through
 any channel."

Maybe both options should be supported.

I can see how some people would like numbered accounts, a la Switzerland.
However, it's not likely. It would be abused. If you want to oppose taxes,
that's one thing, but it should not be confused with the electronic trans-
-fer and maintenance of funds.

It might be more likely to arrange for a compromise where numbered accounts
are permitted iff account balances are publically available also.

This might have interesting spinoffs, such as allowing a much wider range
of interested individuals, access to economic data at the level usually
reserved for banking institutions. We might - as many people have noted -
learn much and contribute accordingly to both economic and cryptographic
theory.

Personally, I think things are much more likely to remain aboveboard if
they are never placed out of sight in the first place except where it is
strictly necessary - and that necessity clearly documented to all.


-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

                    Klein flask for rent. Inquire within.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Sat, 28 Nov 92 00:42:52 PST
To: cypherpunks@toad.com
Subject: Re: ping..mailing list integrity..
Message-ID: <9211280841.AA23039@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



"So if you posted a message, you could check in the evening if it got
 out or not.  If you are not sure if you are receiving all the messages,
 you could maintain a simlar file yourself, and at the end of day compare
 your notes with what is received from the list."

This could be spoofed by an intermediate delivery agent also ...

Generally, in netnews, I regard mail back from individuals or test sites
which honor posts to *.test newsgroups as adequate confirmation. These,
too, could be spoofed, I suppose, but that's a degree of duplicity that
is so complicated to maintain for an indefinite period of time that it is
unlikely to ever be put into practice, IMHO, since it's bound to fail in
the long term, and would probably result in a backlash of disfavor towards
organizations practicing, supporting or funding such behavior.

Perhaps an equivalent service could be implemented where some people's
systems make a point of sending mail directly to posters to verify that
their posting was posted. Bitnet's LISTSERV software does this, which is
very convenient when one is managing a listserver entirely by email from
a few thousand miles away. Other mail servers - Home Brew Digest comes to
mind - do the same thing ...

Grist for the collective mill.

-- richard






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Sat, 28 Nov 92 01:08:42 PST
To: cypherpunks@toad.com
Subject: verification of posting
Message-ID: <9211280907.AA23308@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



Below is a copy of the email I received as a consequence of posting to the
Home Brew Digest.

Of course, the HBD is a digest, not a mail list ... but it occurs to me,
it is much harder to interfere with the operation of a Digest. The Digest
comes out once a day, it has ( usually ) a table of contents at the top,
and, if one received email telling where in the queue one's message was,
one could verify it by reading the Digest when next issued forth. As well
as discussing it with individuals separately via email, which provides a
redundancy of sorts to this verification process.

Eternal vigiliance and all that. Freedom is not a passive process !!


-- richard


> From homebrew-request@hpfcmi.fc.hp.com Fri Nov 27 18:31:24 1992
> Reply-To: homebrew-request@hpfcmi.fc.hp.com
> Errors-To: homebrew-request@hpfcmi.fc.hp.com
> Subject: Re: A clarificatioon on clarification
> 
> 
> 
> (This message has been generated by a program, and is for your
> information only. No further action is necessary.)
> 
> Your article has been received for publication in the Homebrew
> Digest. There are currently 2 article(s) ahead of yours in
> the queue that will be published first.
> 
> Thanks for your submission and your support of the Digest!
> 
> 
> Rob (program author)
> 
> 
> 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: VANGUARD@gribb.hsr.no
Date: Fri, 27 Nov 92 16:37:46 PST
To: cypherpunks@toad.com
Subject: Random numbers
Message-ID: <MAILQUEUE-101.921128014051.448@gribb.hsr.no>
MIME-Version: 1.0
Content-Type: text/plain


    It has lately been discussed different ways to construct pure
random number generators by means of radiactive decay. I must admit
that this is a very good way to produce such numbers, but for a
number of reasons it is impractical to use such a device. (High
radiation levels are needed too produce a significant amount of data.)

    What I have been thinking of is a way to reduce the amount pure
random data needed to produce good random sequences. The way to do
this would too have a weak random number generator like:
R(n+1)=(17*R(n)+1)mod256, and then inject the pure random into this
function giving the result R(n+1)=(17*R(n)+1+PR(t))mod256 or
something of the like.

    Would this constitute a sufficiently secure stream of data for
use in one time pads? Has this been thought of before ?



THE REST OF THIS MESSAGE CAN BE SAFELY INGNORED:

    A friend of mine now serving in the air force gave me a report of
the cryptographic devices used for communicating on permanent lines.
(Twisted pair or something dug down). The machines used till now are
huge totaly outdated mostly mechanical monsters. While not
transmitting data the machines produce random data to hinder traffic
analysys (like how many messages are sent), these data are produced
by cookiebox sized thing, and I strongly suspect it to be of a very
mechanical nature. Thats how a came up with the idea of a very
inexpensive way to produce random data by mechanical means: Use a
contaner filled with marbles some made of conducting, and some of non-
conducting material. Then mix them in some way or another (this is
bound to make a lot of noise) and in the container there should be a
few closely placed points of contact that would be able to send a
small current through a steel ball if it where to pass over the pair
of contacts, and what do we have: Random Data ! (I know this is not
very practical at all)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Sun, 29 Nov 92 07:56:36 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Re: Secure key exchange
Message-ID: <PBgyuB5w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


On Nov 26, Mark inquired about "secure" methods of exchanging public
keys.  Apparently the only really secure method is a physical transfer
face-to-face with someone you know; or to have a key certified by
someone you trust whose key you trust. [PGP has key certification
built-in; for other implementations, just digitally sign some form
of the key to be certified].
 
There is no secure method of exchanging public keys using only the
net.  As far as you know all your messages, both incoming and
outgoing, are being intercepted by a "spoofer" who will substitute
his public key for yours in all outgoing messages and another public
key of his for each unique public key intercepted in incoming mail.
 
A few methods were discussed on Extropians of trying to get a genuine
public key distributed by outsmarting the spoofer. But if the spoofer
is smarter than you, these methods will fail.
 
That leaves methods which exchange, or at least verify, keys by other
means than the network.  I proposed a service to verify keys by paper
mail and (optionally) telephone.  Here is an update of what I posted.
The offer is still good.
================================================================
I'd like to announce the opening of the Swank Public Key Verification
Service.
 
To become a customer, do the following.
 
1)On a piece of paper put:
 
   a)Your name and Network address.
   b)The "armored" ASCii form of your PGP 2.0 Public Key.
   c)(optional) Any other information you want to certify
     about yourself, such as:
      Home address.
      Mailing address (if different).
      Home phone number.
      Occupation-Work Phone-Work Address.
      "I am not a law enforcement officer or agent."
   d)"I certify the above to be true under penalty of perjury".
   e)A photocopy of your driver's license or other picture ID
     with signature.
     Actually this is a photocopy of all of the above with the
     ID on top of the original.
     [note: if you don't want to reveal your home address, you
     can cover that portion of your photo ID. Your name, photo,
     and signature must show]
   f)Your signature. (NOT photocopied)
   g)(optional). have the paper notarized.
 
2)E-mail to me
   edgar@spectrx.saigon.com (Edgar W. Swank)
 
  An ASCII message containing Items a) through d).
  You may encrypt this with my public key (optional).
 
3)Mail to me at
  Edgar W. Swank
  5515 Spinnaker Dr., #4
  San Jose, CA 95123
 
Via U.S. Mail or alternate such as FedEx:
 
  a)The paper prepared as specified above.
  b)A self-addressed, stamped envelope.
    This could also be a pre-paid FedEx envelope.
    It could be addressed to a trusted friend if you're
    concerned your own mail may be intercepted.
  c)$1.00 cash (preferred), check, money order, etc.
    Payment by check will delay processing until check clears.
    If you don't enclose a self-addressed stamped envelope,
    enclose an extra $1.00.
 
That all you have to do. Then what I will do for you:
 
I will visually verify that the public key on the paper matches
the key I received via E-mail and that the signature on your
photocopied ID matches your original signature on the paper.
(I do not claim to be a handwriting expert).
 
I will send to you by return E-Mail your public key signed with
my public key.
 
I will send to you in the evelope you supplied (or to the address
you specify) a paper about myself constructed as described above
(but not notarized - if you want notarized send an extra $10).
This will give you a verification independent of the network
that my public key is really mine.
 
I will post your machine-readable ASCII record that you E-mailed to me
to Extropians and Cypherpunks (optional, specify if you DON'T want
this).  This feature is subject to no objection from Extropians and
Cypherpunks list management.
 
I will keep your paper on file for at least one year.
 
Anyone may request a photocopy of your paper (and up to three others)
by sending me $1 and a self-addressed, stamped envelope.
I will also send your machine-readable ASCII record to his
network address, if supplied.
 
Any customer may also phone me directly at (408)227-3471 during
reasonable hours and I will verify your/others public key(s) by
reading them over the phone.
 
Edgar W. Swank
5515 Spinnaker Dr., #4
San Jose, CA 95123
edgar@spectrx.saigon.com (Edgar W. Swank)
(408)227-3471  (listed)
Cal. Drivers License MO531219
Retired from IBM -- Employee #788281
I am not a law enforcement officer or agent
Here is my PGP 2.0 Public Key:
 
--Type bits/keyID   Date       User ID
--pub  1024/87C0C7 1992/10/17  Edgar W. Swank <edgar@spectrx.saigon.com>
--sig       67F70B              Philip R. Zimmermann <prz@sage.cgd.ucar.edu>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.03
 
mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf
9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2
hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR
tClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIF
ECsRFxzidd4O/2f3CwEBsmID/2qXL/VdjGxxYFNIZdA+DC6howUXlHw66MUArILE
2/9J69VvcpbQTKmD4A+04SwH9q8SDzWxsg+1VANuy08EE0up9pm7ZBzrxkFcOydh
sEwOt9fRn9EJ3tDNYe1SVoxV9Fc47of55Om7cTNrky0hdp1LA13uf/TeV3nrBYa2
1zaz
=IFW+
-----END PGP PUBLIC KEY BLOCK-----
======================================================================
Other Options:
 
If you have a listed phone number and request it, I will verify your
number through information and call you (collect) to verify the public
key you sent me.  I will add this as a notation to your electronic and
paper record.  No extra charge!
 
Another possible option is to use a full color photocopy of your photo
ID.  This costs about $1.00 at photocopy centers such as Photo
Drive-Up as opposed to 5 or 10 cents for an ordinary photocopy.  I
will also note this on your electronic and paper record.
======================================================================
So far I have zero (0) customers. Philip Zimmerman, in e-mail to me,
endorsed the idea, but he has declined to become a customer himself
even though I waived the fee for him.
 
Plan B is to exchange/verify public keys face-to-face at parties,
such as the PenSFA parties I previously posted info about. Rather than
bringing diskettes, I would think printed copies of (armored form)
public keys would be easy to handle. I have printed up business-card
size copies of *fragments* of my public keys with the 6-hex-digit
"Key ID".  I think it would be very difficult to generate a valid new
key pair where the public key matched the key ID and key
fragment.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Sun, 29 Nov 92 07:56:20 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Remailer followup
Message-ID: <7DgyuB6w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


No-one has replied to my request for help using the
remailer at
 
  Remailing Service <hal@alumni.caltech.edu>
 
Am I the only person having trouble making this thing work??
Recall I had to use the "::" convention since I can't specify
network headers (except subject) from this system.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nathanf@cup.portal.com
Date: Sat, 28 Nov 92 08:54:40 PST
To: cypherpunks@toad.com
Subject: unsubscribe nathanf@cup.portal.com
Message-ID: <9211280725.1.15557@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


unsubscribe nathanf@cup.portal.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 28 Nov 92 06:30:11 PST
To: rchilder@us.oracle.com (Richard Childers)
Subject: Re: verification of posting
In-Reply-To: <9211280907.AA23308@rchilder.us.oracle.com>
Message-ID: <9211281429.AA17081@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> Of course, the HBD is a digest, not a mail list ... but it occurs to me,

Digests also introduce a time-delay.  You can have almost-realtime
discussions with an immediate reflector.  

It is possible to have both.  On many mailing lists (such as future-culture
for example) you can "subscribe realtime" or "subscribe digest".

> comes out once a day, it has ( usually ) a table of contents at the top,

I suggest that even if we don't have a digest, we could still have a
"table of contents" at the end of the day.

> and, if one received email telling where in the queue one's message was,

You would not need a receipt message, you would just check to see if you
message appeared in the index.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 28 Nov 92 06:33:06 PST
To: rchilder@us.oracle.com (Richard Childers)
Subject: Re: ping..mailing list integrity..
In-Reply-To: <9211280841.AA23039@rchilder.us.oracle.com>
Message-ID: <9211281432.AA17580@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> "So if you posted a message, you could check in the evening if it got
>  out or not.  If you are not sure if you are receiving all the messages,
>  you could maintain a simlar file yourself, and at the end of day compare
>  your notes with what is received from the list."
> 
> This could be spoofed by an intermediate delivery agent also ...

Not if the evening "verification index" was signed with the list
maintainer's private key.

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tony@morgan.demon.co.uk (Tony Kidson)
Date: Sat, 28 Nov 92 02:43:14 PST
To: cypherpunks@toad.com
Subject: Re: Electronic Banking
Message-ID: <893@morgan.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


In message <9211280427.AA21844@rchilder.us.oracle.com> you write:
>
> "Using the net, the 'banker' could easily be 'offshore' and not
>  subject to US law in these matters."
>
> Feds busted some folks doing just this with modems in Puerto Rico,
> I think it was, within the past year ... heard it on NPR, maybe it
> was BBC or CBC ...
>
>
> -- richard
The 'Feds' writ does not run everywhere. After all, Puerto Rico 
_is_ a US colony.


Tony
------------------+-------------------------------+--------------------------+
| Tony Kidson     |`morgan' is an 8MB  486/33 Cat-| Voice +44 81 466 5127    | 
| Morgan Towers,  |Warmer with a 670 MB Hard Disk.| E-Mail                   |      
| Morgan Road,    |It  resides at Morgan Towers in| tony@morgan.demon.co.uk  |
| Bromley,        |Beautiful  Down Town  Bromley. | tny@cix.compulink.co.uk  |
| England BR1 3QE |            -=<*>=-            | 100024.301@compuserve.com|
+=================+===============================+==========================+




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Alan Hunter <ah@dunaad.co.uk>
Date: Sat, 28 Nov 92 03:26:42 PST
To: cypherpunks@toad.com
Subject: How Far is Too Far
Message-ID: <2b174c79.dunaad@dunaad.co.uk>
MIME-Version: 1.0
Content-Type: text/plain




Phil Karn said:

	I must concur with George Gleason's remarks about "sneaking
	around in the shadows of legality". I find myself getting a
	little uncomfortable with some of the more anarchistic ideas
	expounded in this and similar groups.

	[and lots of other sensible things]

	Just as good fences make good neighbors, we may well find
	that in the hands of the people, good cryptography will make
	for good government.

	That's why I find cryptography so interesting, and that's how
	we should sell it to the public.

And as an authentication tool.  There are many things that, while I
would rather they were private, the authentication aspects are more
important to me. Borrowing Money from the bank, any transaction.
People cotton on very fast to authentication and digital signatures,
they like the idea and buy into the need.

Alan




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 28 Nov 92 07:44:49 PST
To: extropians@gnu.ai.mit.edu
Subject: FutureCulture FAQ
Message-ID: <9211281544.AA19245@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


Does anyone have a copy?  Nyx seems to be down for the last couple
of days so I can't get it.  

Don't send it to me, I don't want to have 150 copies of this fairly
large document pile up in my mailbox overnight, just let me know if
you have it, and I will request ONE of you to send it.

Thanks.

Yanek, yanek@novavax.nova.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 28 Nov 92 07:53:25 PST
To: cypherpunks@toad.com
Subject: Detailed Scenario of Dongle Usage
Message-ID: <9211281553.AA19458@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain




So, you walk up to ANY terminal directly connected to a host, or to a
terminal server, or a personal computer of any kind connected through a
modem, or borrow someone's laptop connected to a cellular modem.

You connect your dongle in between the terminal/computer and the
communications line, and punch in your secret code on the keypad
(which, like phones, also has letters so you can remember fairly long
ID-s).

Call up, or telnet, dial up a bbs, or connect through any other means, to your host,
and log in.

Run your favorite mail reader, let's say _elm_.  Start reading your
mail as you usually would.

Any time an encrypted message is displayed whose public key ID matches
one of the private keys on your keyring, the dongle temporarily buffers
the message it into its RAM, flashes the "decrypt" LED, while
decrypting the message.  Then you can view the plaintext using a
simple, terminal-independent pager that lets you go forward/back one
page, and search for a key word.  When you are done, you press Q, and
the plaintext is immediately deleted from the memory.  Note that during
all this, the plaintext did not appear anywhere on the host or any of
the communication links connecting you to it.

Let's say you want to reply to a message.  Press 'r' or whatever key is
used to reply in your particular mail reader.

Or if you want to send a message, press 'm' and fill in the address.

Then, if your editor is something like vi or ed that requires you to do
something before you can input text (like press 'a') then do that.  If
you use an editor like EMACS or SMiLE or jove or cat or anything that
lets you just type in text, you skip this step.

Now, press the "encrypt" button on the dongle.  It presents you with a
simple line editor, that works with any terminal or terminal emulation,
but is reasonably easy to use (something like most bbs-es use for
composing messages).  You type your message, or if it was prepared
ahead of time on the local equipment, you transmit the text.

NOTE: this is the simpler of the several different approaches to plaintext
handling that I am considering.

When you are done, you pick the public key to encrypt it with (or it
can be automatically determined based on the address you typed in to
your mail program previously).  If you have lots of public keys, you
could use a search to quickly find the one you want.

Then you have the option of signing the message with any one of the
private keys that you have.

Finally, the dongle transmits the cyphertext to the host, and you type
the _exit_ key sequence for the editor (:wq, or C-x C-c, or /done,
etc).

The message is sent by the mailer software on the host.

Then you may want to scan a newsgroup like alt.w.a.s.t.e for any mail
that may be for you.  Put your dongle into "WASTE SCAN" mode (for
example by pressing *WS on the keypad) and tell your newsreader
something like "display all new messages".  The dongle will detect a
message whose key-id matches one of the keys on your key-ring decrypts
and displays it, while ignoring all the other messages that are not for
you.  You must retrieve all the messages, so that anyone monitoring
your activity has no way of knowing which one, if any, was actually
addressed to you.

Then you receive a "talk" request (or a chat call on a bbs, or you may
be on irc or a MUD with "chat mode") from someone you know has a
similar device (or software that emulates it).

If you both know each other's public keys, the two devices both
generate a random session key and encrypt it with the others' public
key.

If not, a key-exchange protocol may be used to generate a key both of
you know, but that can not be later recovered by someone recording the
data.

Now the dongles encrypt any text (one line at at time) that you type,
and decrypt anything received.

Many other applications for a portable, trusted crypto engine could be
thought of, given time.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Sat, 28 Nov 92 10:53:31 PST
To: cypherpunks@toad.com
Subject: bounced mail
Message-ID: <9211281853.AA06156@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



We've made a small change to the way mail gets sent out to the list
which should alleviate the bounced message problem.  The change went
into effect last night.  It should take care of most, but perhaps not
all, of the problems.

So, take heart.  Starting in a few days, please _do_ forward bounce
reports to cypherpunks-request@toad.com.  At that point I'll want them
for further debugging.

Eric
with the list maintainer hat on




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: norm@xanadu.com (Norm Hardy)
Date: Sat, 28 Nov 92 11:50:46 PST
To: cypherpunks@toad.com
Subject: John Gilmore & NSA
Message-ID: <9211281912.AA12654@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


This Saturday's NewYork Times has a nice article on page 7 
regarding NSA's declassification of some of the Friedmann works
under legal pressure from John Gilmore.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 28 Nov 92 12:45:07 PST
To: cypherpunks@toad.com
Subject: Paranoia and Cypherpunks
Message-ID: <9211282040.AA02902@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



PARANOIA, THIS LIST, AND APPROPRIATE TOPICS


It is inevitable that a group such as ours should have varying
opinions about the nature of the group, its role in society, its
approach to outsiders and journalists, and its basic attitude.

Recently, several people have expressed concern that the proper
message is not being conveyed, even that a subversive and seditious
message is often presented on this list. Some have cited discussion of
military cipher systems as being too dangerous for us to discuss,
while others have expressed some discomfort at the "anarchist" flavor
of some postings.

Well, folks, we all have different axes to grind. Since this is an
open, unmoderated list, little control of content can be expected.

* Some want "cryptography" downplayed, to be replaced with "privacy"
as an emphasis. Privacy is seen as more palatable to Americans, less
likely to upset them into cracking down on crypto methods. In other
words, privacy is an easier "sell" than secrecy. 

Perhaps, but why dilute our focus just to make a more digestable pill
for the masses of America, who typically don't think much about
abstractions anyway? Those who want to sell "privacy" are free to.
(BTW, the die was mostly cast when the name "Cypherpunks" was
adopted. That's already raised red flags, just by the name! If we want
to downplay this "crypto-cyber-punks outlaw" image, then a name change
to something more like the "Electronic Frontier Foundation" or the
CPSR, nice, safe-sounding names.)

* Others have expressed some concern that some minor details of how
U.S. cipher machines send out padded traffic were mentioned on this
list--the fear being that discussion of military matters will invite
the scrutiny of the government. Well, check out sci.military some time
and see the debate on such issues! Also, many details of the KG-36,
KWR-37, and Autodin cipher systems--just to cite the specific military
cipher machines that the posting on this list was probably referring
to--have already been published, and the Walker spy ring delivered the
complete specs to these and other machines in the early 1980s.

It's typically only the public who lacks knowledge on these matters.
The Soviets (May They Rest in Pieces) usually got the salient details
fairly quickly.  Since ours is a crypto education group--amongst other
things--what's wrong with discussing any of the gadgets and techniques
that numerous books and other postings have already dealt with?

(Surely John Gilmore's lawsuit to get some critical crypto papers
declassified has already "angered" the folks at NSA. Are we to censure
John for stirring up trouble? Of course not. We're free individuals,
able to say what we wish, meet in secret meetings without the
permission of the government, and learn anything we wish to. This, at
least, is the theory. Until told otherwise, I intend to act on this
theory.)

* Some have argued persuasively for concentrating efforts on the more
palatable (to the public at large) aspects of crypto techniques, such
as authentication to reduce forgeries, privacy protection against
illegal eavesdroppers, and so on. This is the "selling our vision to
the public" point of view.

Fine, it is good for some folks to do this, to concentrate on the
areas that are unlikely to upset Middle America.

But some of us--and you've seen my postings--believe the _selling_ of
these ideas of authentication and privacy is a lost cause, or at least
is not our main interest (e.g, it's not _my_ interest).

* I favor technological solutions over political solutions. Don't call
it sedition, call it the natural trend of new technologies. The
printing press broke the power of medieval guilds in ways a political
approach could never have done. Same with steam engines, electric
motors, incandescent light, copying machines, computers,
modems...well, you get the point.

The things we talk about on this list, the things being developed and
deployed, will have revolutionary effects. I've written about these
effects over the past several years, and this wonderful list is
pursuing them all with gusto! The anonymous remailers alone will set
off alarms throughout the law enforcement community--you're kidding
yourself if you think otherwise. Are we to stop working on anonymous
remailers? What about digital cash? 

Face it, what we're doing will have major implications. To not talk
about these effects, to not speculate on the possible consequences, is
to bury our heads in the sand for fear that someone reading this list
will order this list shut down or have us arrested! 

Yes, it's true some journalists are reading this list. Yes, it's
fairly likely someone is forwarding this list to various agencies
(this isn't paranoia...they'd be fools to not know about this list by
now, given the publicity, the reputations of some of us, etc.). I know
that some of the recipients of the list are gatewaying to other
systems, or are forwarding specific articles to much wider audiences
(I know this partly from e-mail I get). But these are all consequences
of having a public list.

Anyone uncomfortable with the free discussion of ideas and
technologies on this list, anyone who fears personal or professional
liability for views expressed by _others_ on this list, should
probably unsubscribe from the list.

I certainly don't intend to stop writing about the areas that interest
me.

Cheers.

--Tim


--
..........................................................................
Timothy C. May | Crypto Anarchy: encryption, digital money,
tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
408-688-5409 | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pozar@kumr.lns.com (Tim Pozar)
Date: Sat, 28 Nov 92 12:42:31 PST
To: gnu@cygnus.com
Subject: Re: John Gilmore & NSA
In-Reply-To: <9211281912.AA12654@xanadu.xanadu.com>
Message-ID: <m0mvYzK-00020bC@kumr.lns.com>
MIME-Version: 1.0
Content-Type: text/plain


Norm Hardy wrote:
> This Saturday's NewYork Times has a nice article on page 7 
> regarding NSA's declassification of some of the Friedmann works
> under legal pressure from John Gilmore.
 
   Nice picture too! 

              Tim

-- 
Internet: pozar@kumr.lns.com               FidoNet:  Tim Pozar @ 1:125/555
UUCP:     ...!uunet!kumr.lns.com!pozar
Snail:    Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
Voice:    +1 415 788 2022




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 28 Nov 92 10:23:07 PST
Subject: Misc. Items
Message-ID: <921128181712_74076.1041_DHJ61-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


A few random points related to messages from the last few days.

(First, a "meta" point - whenever I post to this list, I get from
3 to about 10 messages over 2 or 3 days reporting on delivery errors.
It would be nicer if these went to someone else.  Some of the messages
include as many as 20 or 30 names of list subscribers who were apparently
included in the same "outgoing batch" as the bounced mail.)

On PGP key verification: I understand that Branko hopes to get version
2.1 of PGP out in a week or so.  One of the new features will be a
mode to display a MD5 hash of each PGP key to facilitate read-aloud
over the telephone.  This should make it easier to phone-verify PGP
keys, so we can have more _good_ sigs.

On pseudonyms and reputations: Several people have suggested that it
would be easy to conjure up dozens of fake personalities who would
then vouch for each other, giving the illusion of a well-founded and
trusted pseudonym.  This would be ideal for con men and cops.

This can be defeated by the use of the is-a-person credential, which
Chaum describes in a couple of his papers, including CACM Oct 1985.
This is a signed document given by an organization which makes you
come in and give your thumbprint.  The document is "re-blinded" a la
Chaums' proposals for electronic cash, so that there can be no linkage
between your is-a-person document and your actual thumbprint.  However,
the thumbprint makes it so you can't get more than one is-a-person
document.

Now, when you go to apply for credit, and you say, here are signatures
from dozens of people that I've done business with in the past, and
I've paid them all off on time, the first thing the creditor is going
to ask is, who are all these people?  Are they legit?  Can you at
least show me is-a-person creds on them?  You won't be able to.  You
only have one is-a-person credential, and you can't make more.

Again, these credentials do _not_ hurt crypto anonymity.  There is no
linkage between your credential and anything else about you.

On electronic banking: The interesting thing about electronic banking
is digital cash.  The key feature of digital cash is anonymity of
payments.  There is nothing subversive about this.  Ordinary cash
has (nearly) this property.  Are you being subversive when you buy
a newspaper without paying by check or credit card?  Of course not.

The point is, we want to use digital payments so that we can transact
business over the net.  But the more things get computerized, the more
possible forms of monitoring there are, by businesses as well as gov-
ernments.  There's nothing immoral in trying to keep VISA from knowing
whom I like to do business with.  Digital cash is designed to allow
the convenience of electronic shopping, while keeping the privacy of
ordinary cash payments.  Conceptually, it's a simple idea.

Technically, what has to be done to turn an electronic banking proposal
such as Don Bellenger's into electronic cash is some way to make it
so that withdrawals can't be paired up with deposits.  You also need,
of course, to prevent cheating such as spending the same piece of cash
twice.  It's not trivial to meet these requirements.  The Chaum proposal
I described is the simplest one that I know of that achieves this.

On remailers: I haven't yet succeeded in doing a doubly-encrypted
remailer test using Bill O'Hanlon's and mine.  Once this works, I'll
post instructions on how to do this, and possibly a script or two to
make it easier.  With two encrypted anonymous remailers, you can for
the first time send anonymous messages such that no one person can
know whom you are sending to.  Bill and I would have to collude to find
out who sent a particular anonymous message.  If more such remailers
can start operating, such collusion will become that much more difficult.

On John Draper: I just wanted to say publically that the famous
"Captain Crunch" was an inspiration to me when I was in college in the
1970's.  Although I did not become a "phone phreak" or "cracker" he
represented to me the spirit of questioning authority and exploring
beyond the accepted bounds of the system.  I have followed his career
to some extent over the years and I think he has more than paid for
any sins he may have committed in his youth.  I for one am thrilled
to have the idol of my younger days on the list.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Sat, 28 Nov 92 13:48:31 PST
To: uunet!novavax.nova.edu!yanek@uunet.UU.NET
Subject: PGP on a multiuser system
In-Reply-To: <9211261554.AA26688@novavax.nova.edu>
Message-ID: <9211282123.AA12941@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


	 You get the picture. There is no security on a multiuser system.

It is possible to get security on a multiuser system (there are at
least B3 rated systems out there), you just can't currently get them
with Windows or Mac interfaces :-)

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Sat, 28 Nov 92 14:20:26 PST
To: uunet!novavax.nova.edu!yanek@uunet.UU.NET
Subject: reputation
In-Reply-To: <9211261521.AA26207@novavax.nova.edu>
Message-ID: <9211282205.AA13176@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


	 What's to stop you (once you have some "reputation") from creating 250
	 other pseudonyms or "identitites", giving them all a "reputation", and then
	 create another identity, and have these 250 all give this one as much as
	 possible, in effect creating an identity with a lot of "credibility" out
	 of thin air?

Even in the simple system I described, there's probably sufficient
feedback to discourage that.  If the identity you went to so much
trouble to promote turns out to be a bozo, then the original identity
loses credibility as a source of recommendation.

Further, the positive recommendations aren't just for filtering,
they're also for sorting.  By spreading the credibility of the first
identity out over 250 others, those 250 identities just don't carry
much weight when my mailer is ordering messages for me to read.  If
reputation is a conserved capital, for instance, they together carry
only as much weight as the first identity that recommended them.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Sat, 28 Nov 92 14:48:27 PST
To: uunet!informix.com!efrem@uunet.UU.NET
Subject: credibility & pseudonyms With digital signatures a dozen secretaries could run a hundred or more pseudoagents, build a solid reputation for each over years.
In-Reply-To: <9211270916.AA25959@godzilla.informix.com>
Message-ID: <9211282227.AA13290@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


	 The same approach would work for a patient con man. 

	 Real credibility has to be tied to a physical body. Some thing
	 at risk.

Real credibility has to be tied to assets.  The credibility is
equivalent to the amount of assets at risk.  In a positive reputation
system, the asset is reputation capital, it is the respect granted by
others.  It embodied in the settings of their sorters that order your
messages before those of other people.

In the farther-out world of nanotech with duplicate bodies and
backups, having a body at risk is worthless because bodies would be
cheap :-)

If the operators of an escrow service are anonymous, then either their
accessible assets had better be enough that you can recover losses if
they walk with your goods, or their opportunity cost of defecting on
their clients had better be high enough (in terms of lost revenue,
lost opportunity on outstanding customer goodwill, name recognition,
channels, etc.) that they are sufficiently unlikely to that you will
take the risk.  Scary prospect, and one which many people will
estimate wrongly, so the simplest strategy would be to only use escrow
companies with an accessible person responsible for them.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Sat, 28 Nov 92 14:48:26 PST
To: uunet!novavax.nova.edu!yanek@uunet.UU.NET
Subject: security on a multiuser system > 	 You get the picture. There is no security on a multiuser system. >  > It is possible to get security on a multiuser system (there are at > least B3 rated systems out there),
In-Reply-To: <9211282159.AA28597@novavax.nova.edu>
Message-ID: <9211282230.AA13299@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


	 That is fine as long as you trust all the entities that designed,
	 built, (modified :-), programmed, installed, and administer the system.

You can inspect the design, the code, the installation, and probablyu
even the administration of the system.  That would typically be
economically infeasible, however, so to reduce your expense, you'll
have to trust someone (preferably someone who stands to lose a lot if
they defect).

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 28 Nov 92 12:00:51 PST
To: cypherpunks@toad.com
Subject: CFP93 information (fwd)
Message-ID: <9211282000.AA25462@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


 The following message was posted to Extropians by Fred Moulton.  
 
 Forwarded message:
 > Message-Id: <9211281835.AA05819@geech.gnu.ai.mit.edu>
 > To: Extropians@gnu.ai.mit.edu
 > Date: Sat, 28 Nov 92 10:31:56 -0800
 > From: moulton@netcom.com (Fred C. Moulton)
 > Subject: CFP93 information
 > 
 > 
 > Attached is some information on CFP93 which might be of interest to some
 > persons on this list.  
 > 
 > Fred
 > 
 > 
 > 
 >                          CFP'93
 >    The Third Conference on Computers, Freedom and Privacy
 >          Sponsored by ACM SIGCOMM, SIGCAS & SIGSAC
 >                     9 - 12 March 1993
 >      San Francisco Airport Marriott Hotel, Burlingame, CA
 > 
 > 
 > SCOPE
 > 
 > The advance of computer and telecommunications technologies holds 
 > great promise for individuals and society. From convenience for 
 > consumers and efficiency in commerce to improved public health and 
 > safety and increased participation in democratic institutions, 
 > these technologies can fundamentally transform our lives.
 > 
 > At the same time these technologies pose threats to the ideals of 
 > a free and open society. Personal privacy is increasingly at risk 
 > from invasion by high-tech surveillance and eavesdropping. The 
 > myriad databases containing personal information maintained in the 
 > public and private sectors expose private life to constant scrutiny. 
 > 
 > Technological advances also enable new forms of illegal activity, 
 > posing new problems for legal and law enforcement officials and 
 > challenging the very definitions of crime and civil liberties. But 
 > technologies used to combat these crimes can threaten the 
 > traditional barriers between the individual and the state.
 > 
 > Even such fundamental notions as speech, assembly and property are 
 > being transformed by these technologies, throwing into question 
 > the basic Constitutional protections that have guarded them. 
 > Similarly, information knows no borders; as the scope of economies 
 > becomes global and as networked communities transcend 
 > international boundaries, ways must be found to reconcile 
 > competing political, social and economic interests in the digital 
 > domain.
 > 
 > The Third Conference on Computers, Freedom and Privacy will 
 > assemble experts, advocates and interested people from a broad 
 > spectrum of disciplines and backgrounds in a balanced public forum 
 > to address the impact of computer and telecommunications 
 > technologies on freedom and privacy in society. Participants will 
 > include people from the fields of computer science, law, business, 
 > research, information, library science, health, public policy, 
 > government, law enforcement, public advocacy and many others.
 > 
 > Topics covered in previous CFP conferences include:
 > 
 > Personal Information and Privacy
 > International Perspectives and Impacts
 > Law Enforcement and Civil Liberties
 > Ethics, Morality and Criminality
 > Electronic Speech, Press and Assembly
 > Who Logs On (Computer & Telecom Networks)
 > Free Speech and the Public Telephone Network
 > Access to Government Information
 > Computer-based Surveillance of Individuals
 > Computers in the Workplace
 > Who Holds the Keys? (Cryptography)
 > Who's in Your Genes? (Genetic Information)
 > Ethics and Education
 > Public Policy for the 21st Century
 > 
 > INFORMATION
 > 
 > For more information on the CFP'93 program and advance 
 > registration, as it becomes available, write to:
 > 
 > 	CFP'93 Information
 > 	2210 Sixth Street
 > 	Berkeley, CA 94710
 > 
 > or send email to:    cfp93@well.sf.ca.us    with the word 
 > "Information" in the subject line.
 > 
 > THE ORGANIZERS
 > 
 > General Chair
 > -------------
 > Bruce R. Koball
 > CFP'93
 > 2210 Sixth Street
 > Berkeley, CA 94710
 > 510-845-1350 (voice)
 > 510-845-3946 (fax)
 > bkoball@well.sf.ca.us
 > 
 > Steering Committee
 > ------------------
 > John Baker                        Mitch Ratcliffe
 > Equifax                           MacWeek Magazine
 > 
 > Mary J. Culnan                    David D. Redell
 > Georgetown University             DEC Systems Research
 >                                    Center
 > Dorothy Denning
 > Georgetown University             Marc Rotenberg
 >                                   Computer Professionals
 > Les Earnest                        for Social Responsibility
 > GeoGroup, Inc.
 >                                   C. James Schmidt
 > Mike Godwin                       San Jose State University
 > Electronic Frontier Foundation
 >                                   Barbara Simons
 > Mark Graham                       IBM
 > Pandora Systems
 >                                   Lee Tien
 > Lance J. Hoffman                  Attorney
 > George Washington University
 >                                   George Trubow
 > Donald G. Ingraham                John Marshall Law School
 > Office of the District Attorney,
 >  Alameda County, CA               Willis Ware
 >                                   Rand Corp.
 > Simona Nass
 > Student - Cardozo Law School      Jim Warren
 >                                   MicroTimes
 > Peter G. Neumann                   & Autodesk, Inc.
 > SRI International
 > 
 > Affiliations are listed for identification only.
 > 
 > 
 > 
 
 

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 28 Nov 92 13:24:30 PST
To: 74076.1041@CompuServe.COM (Hal)
Subject: Re: Crypto Dongle...
In-Reply-To: <921128171942_74076.1041_DHJ49-2@CompuServe.COM>
Message-ID: <9211282124.AA27769@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> Yanek - I do think your dongle idea is promising, but there are a
> couple of other problems I haven't seen you mention.

The concept is by no means complete. I will continue to add
improvements as people suggest them.

> One problem with this is that the terminal programs I use tend not to
> just blast the whole mail message out in literal form, especially
> since it is likely to be longer than one screenful.  Instead, it
> pauses after each screen, prompting with something like "type space
> for next page",

It would be transparent the other way, so that you would press space or
'n' or 'return' or anything you want.

> or such.  Also, it may insert VT100 control sequences as it goes from
> page to page in order to clear the screen, etc.

It should not be too difficult to ignore any codes that are not part of
the data stream.  If the message is coded with something like uuencode
or base64 then the uniform-length lines of data should be clearly
disinguishable from any other text such as "Press N for next screen"
or an escape sequence.

Also, overlapping display (some pagers show you a couple of lines from
the previous screenful) could be dealt with by detecting duplicate
lines.

>> When you are done, you press Q, and the plaintext is immediately
>> deleted from the memory.

> Well, I'd think you'd want the option of saving the plaintext to a
> file on your PC, not always deleting it from memory.

By memory I meant the RAM in the dongle.  If you wanted to save it, you
could have just used to "logifile" function of your communication
software.

> What if you wanted to do what I'm doing here, which is to quote the
> message you are replying to?  

I have not thought about that.

Right away I see several possibilities: one, if the message you are
replying to is the one you just decrypted, it could have been stored in
the buffer, and you can delete the irrelevant lines, and insert your
comments.

The other would be that as you read a message, you could write and
encrypt your reply.  In that case it would also be simple to
automatically use the public key that was used to verify the
signature.

I am sure there are other ways.  There is essentially no limit on
possibilities once you have a CPU.

I will think about it some more.  Thanks for bringing this up.

>> simple line editor, that works with any terminal or terminal

> I think this is OK, although I'm not sure how happy I'd be with
> your line editor, not being accustomed to using BBS's.

You could probably download an editor of your choice into it.  There
could be several editors available.  Maybe even a simple screen editor
that recognizes several most common terminals like vt100 and ansi.

> like I can always compose on my PC, so that's OK.

If your comm software supperted such a feature, the dongle could
transmit a magic sequence which would make the pc to automatically go
into an editor and then transmit the text.  I would imagine eventually
the most popular communication programs would have this feature.  Some
might already.  The point is that if you happen to be using a dumb
terminal or some machine or software WITHOUT this capability you could
still receive and send secure messages.

>> Then you may want to scan a newsgroup like alt.w.a.s.t.e for any mail

>> message whose key-id matches one of the keys on your key-ring,
>> decrypts and displays it, while ignoring all the other messages

> You might have a buffering problem here.  A decryption takes 30
> seconds

They would not be decrypted "on-the-fly".  Each Subject: line would
contain the MD5 hash of the public key.  It would take a fraction of a
second to determine if that hash matches one of your keys for which the
hash values would be precomputed and stored.  Then the message would be
captured.  Later, when the scan is complete, it would be decrypted and
displayed.

> reasons; first, you don't know what flow control the host uses (if
> any), and second, it would expose the fact that you had found a
> message you wanted to decrypt).

That is true.  It should not be a problem though, if there are not too
many messages for you. I plan for the device to have 256k of ram, so it
could hold a few messages.  The ram could be expanded if necessary.

> You can't really anticipate how big the buffer might need to be,
> especially if this method of anonymous communication became popular. 
> As I said in a previous post, you could easily have thousands of
> messages  to sort through, with perhaps dozens for you.

I envision that this method would only be used for short and important
messages, mostly of the form:

  "Contact me by sending mail to xyzzy@anon-r-us.com, key: dfgSDFgds34DF"

So they would be short, easy to buffer, quick to decrypt and hopefully
not too many of them.  If there WAS too many messages, more than you
were able to buffer, then it would just ignore the rest, process the
ones it did get, and then you would request a second scan during which
the first ones (that have already been processed) would be ignored, and
the rest would be received.  The problem with this is that the host
would know that if you scan twice you have a lot of messages. They dont
know which ones though.  Or maybe you just had a transmission error...

> solution than just encouraging people to buy laptops and use them? 

Most people that use e-mail already have a computer, They may not want
to buy another one.  They may use the computer or terminal on their
desk for other things too, and would not want the inconvenience of
having to use a separate screen/keyboard anytime they receive or want
to send a private message.

Laptop will cost more.  Why buy a screen, keyboard, disk drive if you
already have it.  Hopefully my device will be cheap.  It should be
cheaper than any laptop.  All I have is two serial ports, a cpu, some
RAM and support cirquitry.  I don't have a full-fledged keyboard,
display, disk (or card) drive, and all the other stuff that goes in a
laptop.  

Laptops are bigger.  Or if they are small, they have lousy
screens/keyboards.  I hope to make my device smaller than even the
so-called "palmtops".  It would be easier to carry with you, in your
pocket.  It would be easier to hide if necessary.

You can't make a laptop.  You cant easily open it up, or if you can, it
is complex enough that you can not completely understand its design.

You can make a dongle from a kit, testing each part before you assemble
it.  You could make one from scratch.  You can design one if you don't
trust the schematics.  Or you could show it to a competent electronics
engineer and he could tell you if it does what it says it will.

A laptop is not designed with security in mind.

If you find that someone has just learned your secret code (that you
used to encrypt your private key) and are going to seize your laptop in
15 seconds, you can't immediately destroy the key (you need to turn it
on, boot or resume, exit from whatever program you were running or
create a new window, CD to the directory where you store your private
key, delete the file, run some program that makes sure the sectors are
cleared.)  And you still can't be sure that the key is not stored in
some buffer or disk or cpu cache or a temporary file.

Compare this with punching in a short "DESTRUCT" sequence on the
keypad; if you have the device in your pocket, you can even do it
without taking it out of your pocket, if you know the keypad well; And
be absolutely sure that all information is completely gone.

> Despite my negative comments here, I think there is room for plenty
> of different approaches to making crypto easier to use.

Absolutely.  I am not saying that a hardware device designed
specifically for cryptography is the ONLY way to go, what I do believe
is that it is just a very good way to make easy access to cryptography
widespread.

A person that does not even know enough to be able to download, uncompress
and install a software package could get one of these devices and make
use of it.  And there is no limit as to what a knowledgeable person
could do with such a device.

>If the dongle really could be made available at the price level you
>mentioned, there might be some interest ...  and if there was one for
>$200 or less that would definately be interesting to me.

Right now I hope to make it available for about $100. I don't know if I
can yet, but will find out soon.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 28 Nov 92 14:00:11 PST
To: xanadu!tribble@uunet.UU.NET (E. Dean Tribble)
Subject: security on a multiuser system
In-Reply-To: <9211282123.AA12941@xanadu.xanadu.com>
Message-ID: <9211282159.AA28597@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> 	 You get the picture. There is no security on a multiuser system.
> 
> It is possible to get security on a multiuser system (there are at
> least B3 rated systems out there),

That is fine as long as you trust all the entities that designed,
built, (modified :-), programmed, installed, and administer the system.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Sat, 28 Nov 92 17:59:17 PST
To: "George A. Gleason" <gg@well.sf.ca.us>
Subject: Re: Electronic Banking
In-Reply-To: <199211261116.AA24529@well.sf.ca.us>
Message-ID: <9211290158.AA22750@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I think we should set up a digital money system, and just take the legal
risks.  I volunteer.

On a related note, I noticed an article on electronic money in a recent
issue of _the_Futurist_.  It kept on coming back to the big advantage of
cryptomoney:  it is completely traceable.  The main point was that
cryptomoney would eliminate black marketeering (including the drug trade).
The author said it would be wonderful for the federal government to run this
new system, for several reasons.  First, it would allow them to monitor all
activity, so there could be no tax evasion or black marketeering.  Second,
we would all be safe knowing that the government kept the information
confidential, so it couldn't be used imporoperly.

This was a scary article.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Sat, 28 Nov 92 18:25:32 PST
To: yanek@novavax.nova.edu (Yanek Martinson)
Subject: Re: comments on Don's "Cypher Bank"
In-Reply-To: <9211271825.AA25349@novavax.nova.edu>
Message-ID: <9211290225.AA24130@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>If only the hash value is mailed, then the full key can be e-mailed
>or anonymously posted to a newsgroup that you montitor.  If the full key
>is mailed, you should invest in a scanner and some simple OCR software.

I have been thinking about this.  I think that pgp should have a postscript
output module, so you can print your public key on the back of business
cards and hand them out to people you meet.  Or businesses could put it on
thier flyers.  Or many other uses for times when you don't want to have to
have your computer there to exchange keys and you don't want to exchange
disks because they're expensive and big and have lots of different
incompatible formats (and some people, like me for instance, don't have any
disk drives).

I think the best font for this would be a font like OCRA, the font used at
the bottom of checks.  This font allows for very reliable scanning.  Does
anyone know where I can get a postscript version of this font?  If someone
can find it, I'll write a program that outputs a public key in that font in
the right size for a business card.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Sat, 28 Nov 92 20:01:51 PST
To: cypherpunks@toad.com
Subject: credibility and banking
Message-ID: <9211290400.AA00660@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



"If the operators of an escrow service are anonymous, then either their
 accessible assets had better be enough that you can recover losses if
 they walk with your goods, or their opportunity cost of defecting on
 their clients had better be high enough (in terms of lost revenue,
 lost opportunity on outstanding customer goodwill, name recognition,
 channels, etc.) that they are sufficiently unlikely to that you will
 take the risk."

It seems to me that there are many parallels between this state of affairs
and that which prevailed in the American West of the 1800s, with respect
to banking .... there were no agencies insuring deposits, and only the rep-
-utation of the bank's president - usually a leader of the community - was
guarantee upon the funds. Bank robberies were not uncommon, depositors were
few, runs on the bank, I speculate, may not have been unknown in those cir-
-cumstances where the community of bank depositors lost confidence in the
bank or its officers.

Another parallel which occurs to me is that of the computerized trading that
occurred when programs controlled trading in, um, was it October of 1987 that
the stock market shuddered ? 1989 ? ... it suggests the inevitability of
software shuttling funds around at cyberspace speeds to take advantage of
ebbs and flows in the economic tides of the human race, around the world ...

It would be interesting to further study the origins of banking, as I expect
such a study would provide many such parallels by which the case for digi-
-tized banking could be made stronger ...

-- richard





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Sat, 28 Nov 92 20:08:47 PST
To: cypherpunks@toad.com
Subject: Re: Electronic Banking
Message-ID: <9211290407.AA00714@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



"On a related note, I noticed an article on electronic money in a recent
 issue of _the_Futurist_.  It kept on coming back to the big advantage of
 cryptomoney:  it is completely traceable.  The main point was that
 cryptomoney would eliminate black marketeering (including the drug trade)."

I don't think cash will _ever_ be eliminated. If it is, someone will make
their own ( banks did this for many decades in North America ) and these
will fill the role.

There will always be transactions which will not justify the cost of the
overhead in hardware and transaction processing, and market pressures will
reward those whom develop a way to avoid this overhead, IMHO.

-- richard





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Sat, 28 Nov 92 04:39:57 PST
To: cypherpunks@toad.com
Subject: Re:  comments on Don's "Cypher Bank"
Message-ID: <9211281239.AA00261@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


richard childers (rchilder@us.oracle.com) :
>It might be more likely to arrange for a compromise where numbered accounts
>are permitted iff account balances are publically available also.
>
>This might have interesting spinoffs, such as allowing a much wider range
>of interested individuals, access to economic data at the level usually
>reserved for banking institutions. We might - as many people have noted -
>learn much and contribute accordingly to both economic and cryptographic
>theory.

It is said information should be free... however, if someone was (and someone
undoubtedly would), to monitor the bank(s) they would probably see accounts
going up and down by various amounts and it should be possible to track 
transactions between identities. This, coupled with widespread traffic
analysis (assuming no padding had occured) would allow someone to deduce that
Alice had asked something of Bob and had then paid him. This probably isnt 
particularly inviting to the majority to know that your funds could be traced
very anonymously and that patterns could be formulated... for instance three
times a month various amounts are deducted from your account and those exact
same amounts appear in an account known to be owned by a 1-900 phone sex 
number. That would have an affect on your reputation, (if not your marriage
if your True Name was known), if it was published. (The 1-900's identity
could be discovered simply by someone using the service and noting what
psuedonym took your funds, or if that was changed, noting which account
increased by your $127.30. (It was an intense call I guess :)

If you wish to entertain such a testbed financial system be very careful with
any decision made and work through each possible consequence. Most people I
think would prefer to remain anonymous. I know I would, in the long run.

Mark
mark@coombs.anu.edu.au





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu (John Gilmore)
Date: Sat, 28 Nov 92 23:40:54 PST
To: cypherpunks
Subject: George Gleason speaks out about cryptography:  Today 2PM Berkeley.
Message-ID: <9211290740.AA13833@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


BMUG, Inc. 	Computer Professionals for Social Responsibility
      .     .     .     .     .     .     .    Berkeley Chapter
_______________________________________________________________
FOR IMMEDIATE RELEASE
Contact: Judi Clark, 549-2684 (BMUG), 261-1869 (direct),
fax: 261-4836 (direct), or e-mail judic@netcom.com
November 27, 1992
 
Special Interest Group on Freedom, Privacy and Technology
A public forum co-sponsored by BMUG and CPSR/Berkeley
 
For those that need a brief break from Thanksgiving, the 
CPSR/BMUG Special Interest Group will explore cryptography
with a brief overview and discussion lead by George Gleason.
 
Gleason is founder of a telecommunications contracting
firm in Berkeley. He is also professionally involved in 
psychological research on interpersonal communication and 
state variables (i.e. perception, cognition, etc.).
 
Gleason's overview will be followed by a video taken from the
Second Conference on Computers, Freedom and Privacy in 
Washington DC last March. The video is entitled: "Who Holds 
the Keys? Cryptography & Control: National Security vs. 
Personal Privacy."
 
You are encouraged to join us on November 29, 1992 at 2:00 pm
for a look into cryptography and personal privacy.
 
The Special Interest Group's next meeting is Sunday, Nov. 29, 
1992, at 2:00 pm. The monthly meetings are free and open to the 
public. The group meets on the last Sunday of the month at the 
BMUG office, 2055 Center Street, Berkeley -- a half block from the 
Berkeley Bart station.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 28 Nov 92 20:46:59 PST
To: rchilder@us.oracle.com (Richard Childers)
Subject: Governmental Economic Control
In-Reply-To: <9211290407.AA00714@rchilder.us.oracle.com>
Message-ID: <9211290446.AA07027@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> I don't think cash will _ever_ be eliminated. 

> There will always be transactions which will not justify the cost of the
> overhead in hardware and transaction processing, and market pressures will
> reward those whom develop a way to avoid this overhead, IMHO.

You can not depend on this.  The government may subsidize the
transactions, reducing or elimintating the overhead.  For example it
may issue "free" (paid for by money extorted from you) Personal
Identitiy Cards, and install "public" Funds Transfer Terminals in most
public locations.

It may pass laws requiring every business to accept it (just write
"This Card is a Legal Tender..." on the card).

Then the only incentive for bypassing the system would be desire for
privacy, which, for the average American, is much weaker than the
economic incentive.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu (John Gilmore)
Date: Sat, 28 Nov 92 23:56:27 PST
To: yanek@novavax.nova.edu (Yanek Martinson)
Subject: Re: Detailed Scenario of Dongle Usage
In-Reply-To: <9211281553.AA19458@novavax.nova.edu>
Message-ID: <9211290756.AA14123@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Yanek's scenario might have been great for 1980, but in 1993, if your
electronic mail doesn't come right down into the computer in front
of you, that you trust, I want to know why not.  It works this way
for millions of Internet users, AppleLink users, and users of "offline
edit" programs for MCI Mail, ATT Mail, compuserve, AOL, Prodigy, etc.

It's cheaper to buy computers these days than terminals!  Seriously!

	John Gilmore

PS: Don't tell the list -- we've had more than enough traffic
recently.  Tell *me* (gnu@toad.com) why you use your computer like a
terminal instead of like a computer.  I'll be gone for a week, so 
lack of speedy replies doesn't mean I'm not listening.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sun, 29 Nov 92 00:52:05 PST
To: hh@soda.berkeley.edu
Subject: Re: Electronic Banking
Message-ID: <199211290850.AA03386@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


"...and just take the legal risks..."  Wellll, what is there to gain by
taking legal risks, as opposed to doing a research gig where we're trading
in pennies for fictitious goods & services...?  Please spell it out
explicitly; there would have to be a very significant advantage to convince
me to agree.  Like maybe that the govt is about to pull all cash out of
circulation and this is our last hope....

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Sun, 29 Nov 92 01:01:10 PST
To: cypherpunks@toad.com
Subject: "gleason speaks at CPSR..."
Message-ID: <199211290859.AA04170@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



Just a quick note of reassurance here.  Someone at BMUG saw something I
posted about crypto and education and values, and suggested I give a short
talk on that to get discussion going.  I will definitely Not 1) be a
"spokesperson" for anything or anyone other than my own views, and 2) say
anything likely to arouse premature publicity regarding things going on in
the group or on the list.  So in other words I intend to play it way
careful, low-key, stick to social issues, and make it clear that there are
many people far more qualified than I to discuss technical aspects in
detail, and make it clear that there is wide debate and difference of
opinion on the subjects of discussion.  

Now also, apologies for not contacting other folks on the list here when
this was just getting set up.  Actually it surprised the heck out of me to
find out how fast the date came up; I was expecting at least another week.
Properly, there are at least ten or twenty people on our list who could be
addressing other groups on these issues.   Any feedback, email back to me
quick, because it's about 12 hours from now...!

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Sun, 29 Nov 92 07:38:56 PST
To: cypherpunks@toad.com
Subject: crypto banking
Message-ID: <9211291538.AA23755@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



I'd like to see a digital bank go up as well - just to be able to work
through the protocol, at first.  I took a cryptography course last
summer at the university, and learned a lot (and had some fun!)
working through various protocols: coin flipping, poker, subliminal
channels, number comparison without giving away the numbers involved,
signatures, etc., and more recently since joining this group: dc-nets.
It doesn't have to be fancy: this list or maybe just email between
various participants at first, maybe then a fancier system with
transactions posted or made public for study, then a more advanced
system with telnet or mail to the digital bank and transactions kept
private.  We could make everybody's account balance public and then
study ways to avoid traffic analysis on account fluctuations (maybe
the only way to do this is to keep balances secret) - maybe everyone
can have more than one account and pay off transactions with a little
bit from each account (this would be inconvenient though...)
	Anyway, I'm just rambling on... :-)

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Sun, 29 Nov 92 11:13:33 PST
To: gg@well.sf.ca.us
Subject: Electronic Banking
In-Reply-To: <199211290850.AA03386@well.sf.ca.us>
Message-ID: <9211291912.AA07318@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


    "...and just take the legal risks..."  Wellll, what is there to gain by
    taking legal risks, as opposed to doing a research gig where we're trading
    in pennies for fictitious goods & services...?  Please spell it out
    explicitly; there would have to be a very significant advantage to convince
    me to agree.  Like maybe that the govt is about to pull all cash out of
    circulation and this is our last hope....

How about a crypto poker game, or crypto diplomacy (with fictitious
money)?  This would allow us to try some coin flip protocols, zero
knowledge proofs etc. as well as crypto banking.  Of course, cheating
(trying to rig the coin tosses, spoof messages etc.) would be
encouraged!  That would allow us to find weak spots in the protocols,
which are supposed to prevent this from happening.  Then, at the next
physical meeting, people could describe what kinds of things they did,
and maybe the winner could get a small prize (e.g. be treated to
dinner by the rest of the players).




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Sun, 29 Nov 92 10:38:53 PST
To: cypherpunks@toad.com
Subject: comments on Don's "Cypher Bank"
In-Reply-To: <9211290225.AA24130@soda.berkeley.edu>
Message-ID: <9211291813.AA23423@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain



>>If only the hash value is mailed, then the full key can be e-mailed
>>or anonymously posted to a newsgroup that you montitor.  If the full key
>>is mailed, you should invest in a scanner and some simple OCR software.

>I have been thinking about this.  I think that pgp should have a postscript
>output module, so you can print your public key on the back of business
>cards and hand them out to people you meet.

Is anything preventing you from building seperate tools to do this?
PGP will happily put out your key into a file, from whence you can do
anything you like. Why add bloody postscript generation capability to
an encryption program, fercrissake.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Sun, 29 Nov 92 11:07:39 PST
To: gg@well.sf.ca.us
Subject: the list
In-Reply-To: <199211290859.AA04170@well.sf.ca.us>
Message-ID: <9211291832.AA23438@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: George A. Gleason <gg@well.sf.ca.us>

>Just a quick note of reassurance here.  Someone at BMUG saw something I
>posted about crypto and education and values, and suggested I give a short
>talk on that to get discussion going.  I will definitely Not 1) be a
>"spokesperson" for anything or anyone other than my own views, and 2) say
>anything likely to arouse premature publicity regarding things going on in
>the group or on the list.

"Premature" publicity? This list isn't exactly a private club -- I bet
the government folks know exactly what it is we are discussing and in
great detail. Posting something to a list like this means it isn't a
secret any longer. Not that we are much of a threat -- the average
subscriber here seems to have far more opinions than knowledge.

If you have something you want to see done, just go out and do it.
Don't form a committee to discuss the matter. Things that get
discussed on this list immediately enter my list of things I'm
unlikely to see anyone else build any time soon.

Sorry for lashing out, but the drivel is getting thick enough to cut
with a chainsaw. Repeating, if you want to do something, just go out
and do it, don't talk.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Sun, 29 Nov 92 14:04:10 PST
To: edgar@spectrx.Saigon.COM
Subject: Re: Secure key exchange
Message-ID: <9211292203.AA17336@servo>
MIME-Version: 1.0
Content-Type: text/plain


How byzantine!

PGP 2.1 will have a much more convenient facility for verifying public
keys that you receive over the network. If you say "pgp -kvc karn",
for example, it will display the MD-5 hash of karn's public key as 16
hex bytes. If you know the sound of my voice, you can call me on the
phone and have me read off the hash code that I compute here on my key
so you can compare it to the value you computed. If they match, you
can sign my key with reasonable confidence.

About the only way to defeat this system is for the bad guy who feeds
you the bogus key in my name to come to my house and hold a gun to my
head as I receive your phone call.

I would much rather trust a simple verification procedure based on
redundancy and close personal relationships than a single, complex,
impersonal process involving people I don't know. This is not to
impugn your integrity, of course -- I'm simply speaking on principle.

People need to be very selective about the signatures they sign,
otherwise they will become meaningless. I've already had people sign
my public key without any verification that it is legit. This is a
no-no.  I am bothered by the message that PGP currently generates when
it reads in some new public keys asking if you'd like to certify each
new key. Even though the default is "no", it makes it too easy to sign
a key without really verifying its authenticity.

Phil





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc Horowitz <marc@MIT.EDU>
Date: Sun, 29 Nov 92 13:27:17 PST
To: cypherpunks@toad.com
Subject: crypto dongle design problems
Message-ID: <9211292126.AA22394@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


A few comments on "Detailed Scenario of Dongle Usage":

>> So, you walk up to ANY terminal directly connected to a host, or to a
>> terminal server, or a personal computer of any kind connected through a
>> modem, or borrow someone's laptop connected to a cellular modem.

As several people have pointed out, terminals are passe'.  In general,
my mail never goes over a serial line.  Here at MIT, most people have
unix machines on their desks.  Mail is composed on the unix machine,
sent via ethernet to the mail hub, and received via POP or NFS from
the mailhub.  To make life worse, often, the machines are in public
clusters where anyone can log in.  And, (sit down here), the root
password for these public machines is well known.  (The servers' root
passwords are a closely guarded secret.)  So, for me, the
crypto-dongle is almost completely useless. 

>> Call up, or telnet, dial up a bbs, or connect through any other means,
>> to your host, and log in.

Except IP.  One of my machine at work runs SLIP over its serial port.
What am I supposed to do now?

>> Any time an encrypted message is displayed whose public key ID matches
>> one of the private keys on your keyring, the dongle temporarily buffers
>> the message it into its RAM, flashes the "decrypt" LED, while
>> decrypting the message. 

Someone else mentioned this, but I didn't understand your response.  I
read mail in emacs, a full-screen editor.  it displays the first
screenfull, and I hit space to scroll down.  Does the dongle recognize
emacs and hit space, or what?

>> Now, press the "encrypt" button on the dongle.  It presents you with a
>> simple line editor, that works with any terminal or terminal emulation,
>> but is reasonably easy to use (something like most bbs-es use for
>> composing messages).  You type your message, or if it was prepared
>> ahead of time on the local equipment, you transmit the text.

So, I'm trusting the local equipment with my private message.  Even if
I'm only "typing directly to the serial port", how do I know if my
friend's borrowed laptop has been (maybe unknowingly) modified to
store the data?

Similar problems arise with all the other sample applications you
describe.

More personal comments:

I've had several years of experience designing large-scale systems
incorporating security features.  One of the most valuable lessons
learned is that security and privacy must be designed into a system
from the beginning, not added later.  Ease of use comes from design,
not hacks, which inevitably fail.

My view of a useful crypto-dongle is more like Phil's.  A device with
one serial port, which stores my private keyring.  It has functions to
list the keys it has (names and hashes, not keys), to decrypt a
message (while displaying some external indication of having done so),
and to sign a message (again, with display).  Programs would have to
be modified to use the dongle to do the appropriate very sensitive
crypto stuff, and I can do the DES or other work on my desktop
machine.  I forsee the dongle being made of a well-known CPU or MCU
(easily verifiable), an EPROM (software), a static RAM (long-term,
encrypted storage of keys), a DRAM (short-term cleartext storage and
buffering), a UART, an input keypad of some sort, a small (say 1x20
LCD display for simple output, and perhaps a special chip for the
math.  Sources to the EPROM would be available, of course.  Paranoid
people could burn their own chip (assuming they trusted the programmer
:-).  Yeah, this isn't much use on a dumb terminal, but dumb terminals
aren't of much use nowadays, anyway.

		Marc





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mcmahonm@wybbs.mi.org (Mike McMahon)
Date: Sun, 29 Nov 92 14:51:00 PST
To: cypherpunks@toad.com
Subject: UNSUBSCRIBE
Message-ID: <9211291635.AA01230@wybbs.mi.org>
MIME-Version: 1.0
Content-Type: text/plain


unsubcribe mcmahonm@wybbs.mi.org





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc Horowitz <marc@MIT.EDU>
Date: Sun, 29 Nov 92 13:43:41 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9211292143.AA22427@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


>> This entire business may be pretty simple.  If we have anonymity
>> both ways, (where one or neither party knows the others physical
>> location), then who cares about the content of the message? 
>>  
>> You might as well send it in plain text,  Except you need RSA
>> just for the signitures so you know you aren't being spoofed.

Very good reasons.

"Here is my plan to kill President Foo: ...."

Just because you and your hired gun are anonymous, you don't want
anyone, especially the government, to read your message.  It could
throw a wrench into your plans.

		Marc




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc Horowitz <marc@MIT.EDU>
Date: Sun, 29 Nov 92 14:08:03 PST
To: cypherpunks@toad.com
Subject: thoughts on digital cash
Message-ID: <9211292207.AA22455@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


I've thought a bit about digital cash since the thread started here,
and I have a bunch of thoughts.  I hope I'll be coherent.

** For production use, you want a real, live bank or other entity to
issue the "money".  Assuming the digital cash is backed by gold, or
securities, or something else tangible, you don't want the bank to go
away with all your money.  Or, if you read in the newspaper "Feds
seize First National Bank", you want to know if they've just seized
*your* bank, and therefore will be able to watch your deposits and
withdrawals.  If you don't know who your bank really is, you won't
know.

** All of the above applies to your escrow agent (who may be your
bank) for similar reasons.  Public key systems provide
non-repudiability, but knowing provably that a pseudonym just stole
money or goods from you doesn't help you get it back.  Sure, it
tarnishes their reputation, but if they steal a whole lot of money all
at once, they won't care.

** Anonymity in banking is a well-known concept.  If I transfer money
from my numbered swiss bank account to your numbered swiss bank
account, nobody knows anything, except who the bank is.  And I don't
see Switzerland giving up their enviable position in the international
banking community willingly.  All we need to do is convince a swiss
bank to do some digital cash banking.  Easier said than done.

** Legality of starting our own anonymous electronic bank: what do the
laws say, anyway?  As long as I pay taxes on any profit, I can form a
sole proprietorship to freely buy and sell purple widgets with very
little government interaction.  Would it still be legal if I got a
whole lot of people to accept purple widgets instead of cash?  Would
it be legal if we called it "digital purple widgets" instead of
"digital cash"?


I'd really like to see some sort of digital cash system set up.  My
feeling is that there would be a stronger demand than most people
think for such a thing, even if it weren't anonymous and untraceable
and all that.  But if it has those features, too, and we do it first,
it will get used.  And de facto standards are hard to get rid of.

		Marc




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: S950272@slvaxa.umsl.edu
Date: Sun, 29 Nov 92 15:19:41 PST
To: cypherpunks@toad.com
Subject: Please...
Message-ID: <01GRQCRO6QHG8WW8IZ@slvaxa.umsl.edu>
MIME-Version: 1.0
Content-Type: text/plain


Please delete me from the mailing list, the mail volume is too great for me.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc Horowitz <marc@MIT.EDU>
Date: Sun, 29 Nov 92 15:25:14 PST
To: cypherpunks@toad.com
Subject: unsubscribe messages
Message-ID: <9211292324.AA22516@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


If you don't want to be on this list, that's fine.

BUT PLEASE STOP CLUTTERING MY INBOX WITH THE UNSUBSCRIBE REQUESTS!!! I
AND MOST OF THE OTHER RECIPIENTS OF THIS LIST CANNOT DO ANYTHING ABOUT
IT!!

There is a convention on the Internet that if there is a list called
foo@bar.domain, the maintainers of this list will be on a much smaller
list called foo-request@bar.domain.  Send requests there to get added
or removed, not to the whole list.  If you get a bounce, then, and
ONLY THEN, should you send to the whole list.

So, if you want to get off the list, send mail to
cypherpunks-request@toad.com.  It's not hard.  And it will keep large
numbers of people from wanting to kill you.

Flame off.

		Marc




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: cmr!cmrp!berry_k@mailer.cc.fsu.edu (Kevin Berry)
Date: Sun, 29 Nov 92 15:53:56 PST
To: cypherpunks@toad.com
Subject: UNSUBSCRIBE
Message-ID: <9211292336.AA19892@cmrp.cmr.uucp>
MIME-Version: 1.0
Content-Type: text/plain


unsubscribe berry_k@cmr.fsu.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill O'Hanlon <wmo@rebma.rebma.mn.org>
Date: Sun, 29 Nov 92 20:24:59 PST
To: cypherpunks@toad.com
Subject: Some hacked scripts for the remailers
Message-ID: <m0mw2OO-000A4zC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


Here's a couple of real rough Bourne shell scripts to get some mail
to go to both Hal's and my remailers.  Not too helpful if you don't
have a unix machine around--sorry.  Nothing fancy, but it'll keep the
mental confusion down when trying to put a message together.

First is twohop...
------ Cut here ------
#!/bin/sh

# Two hop anonymous remailer  hal's first, then rebma ...

if [ $# != 2 ]
then 
	echo Usage: twohop message-file-name destination-address
	exit 1
fi

message=$1
dest=$2
t1=twohop.1
t2=twohop.2

# if the "remailing" and "remailer" names look odd--well, that's what hal's
# and my respective keys for the remailers are named...


encap $message $dest remailer $t1
encap $t1 remailer@rebma.mn.org remailing $t2

elm hal@alumni.caltech.edu < $t2

rm -f $t1 $t2
----- Cut here -----

twohop calls encap twice.  Encap is a more general and useful script.

------ Cut here ------
#!/bin/sh

#
# usage: encap message-file destination remailer resultfile
#

if [ $# != 4 ]
then
	echo Usage: encap message-file-name destination remailer-key-name outputfile
	exit 1
fi

mfile=$1
dest=$2
remailer=$3
result=$4

t1=encap.1
t2=encap.2

echo :: > $t1
echo Request-Remailing-To: $dest >> $t1
echo "" >> $t1
cat $mfile >> $t1
pgp -ea $t1 $remailer
echo :: > $t2
echo Encrypted: PGP >> $t2
echo "" >> $t2
cat $t1.asc >> $t2

mv $t2 $result
rm -f $t1

---- Cut here -----


These seem to work for me...  At least, a couple messages now have gotten
back to me from them.  They helped me get a couple problems out of
the remailer.

-Bill
-- 
Bill O'Hanlon						 wmo@rebma.mn.org



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Mon, 30 Nov 92 00:33:34 PST
To: edgar@spectrx.Saigon.COM
Subject: Re: Secure key exchange
Message-ID: <199211300832.AA16031@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Edgar-

Two possible points of critique in an otherwise good idea.
1) HOME Address?!  As I've said before, that's arguably your most secure
datum since it's where you keep your soft, squishy body, and where the
baddies and black-baggers and so on would just looove to know where to find
you.  Let's not make it any easier for them.  

2) "I certify that I'm not a cop or spy."  That doesn't and hasn't ever held
up in any court in the land.  Plenty of precedent in drug case law.  "I want
to buy some pot."  "Okay, first tell me under oath that you're not a nark."
Result: nark laughs all the way to the police station, with fresh catch in
handcuffs.  We can't keep them out, and at some future time might want to
open up a dialog with the LE community on various issues.  No point looking
like a conspiracy if we aren't one.

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: strat@intercon.com (Bob Stratton)
Date: Mon, 30 Nov 92 01:30:00 PST
To: cypherpunks@toad.com
Subject: Secure key exchange
In-Reply-To: <9211292203.AA17336@servo>
Message-ID: <9211300930.AA00855@intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


>>>>> On Sun, 29 Nov 92 14:03:25 -0800, karn@qualcomm.com (Phil Karn) said:


	Phil> People need to be very selective about the signatures
	Phil> they sign, otherwise they will become meaningless. I've
	Phil> already had people sign my public key without any
	Phil> verification that it is legit. This is a no-no.  I am
	Phil> bothered by the message that PGP currently generates
	Phil> when it reads in some new public keys asking if you'd
	Phil> like to certify each new key. Even though the default is
	Phil> "no", it makes it too easy to sign a key without really
	Phil> verifying its authenticity.

I have to echo Phil's comments here. One of the things that might be
worth a few minutes is for this group to hash out (pun intended) a set
of guidelines for "when it's o.k. to sign a key". I have been
talking to some people about personal applications of cryptographic
technology, and I'm frequently surprised when even people with a DP
security background want to rush to certify keys they've received via
email, etc. 

I'm thinking something along the lines of "If I'm in a real-time
communications mechanism, and on the phone at the same time, and I
receive their key at the moment when they told me they hit the return
key - then it's probably theirs"...It would be prohibitive to list all
of the possible permutations, but it might go a long way toward
building the right habits if we brainstormed about a few firm
guidelines for the uninitiated as to what constitutes responsible key
management. 

I confess to some personal bias, because I know the PEM folks are
watching to see how robust our key distribution "web" becomes over the
course of its evolution, and I'd like to be able to show them a
convincing argument against centralized key management, empirically...

--Strat






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 30 Nov 92 08:18:40 PST
To: cypherpunks@toad.com
Subject: Electronic Banking
In-Reply-To: <9211251953.AA01487@nano.noname>
Message-ID: <9211301618.AA14930@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



[Hal Finney describes Chaum's blind signature scheme.]

>The "social" problems are more challenging, it seems to me.  

One such social problem that Hal does not mention is that the blind
signature is a patented algorithm.  You'd have to get a signature from
Chaum.  Since any such company which wanted to deploy with blind
signatures whould be competing with Chaum's own company, DigiCash,
there might be a problem here.

>One possibility is to base digital cash on real money.  

>Unfortunately, this approach would currently be illegal (at least,
>unless you actually were a real bank!).  

If you wanted to do this as a business, you can start a bank with
(roughly) a million dollars in capital or you can buy an existing one
with at minimum (roughly) fifty thousand.  These minimum investments
are for bank regulation purposes, not operating costs.

So, if you really want to _be_ a bank, it's not that hard.  Your
greatest startup expense will most likely be attorney's fees for a
specialist in bank regulation law.

Eric





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pfarrell@cs.gmu.edu (Pat Farrell)
Date: Mon, 30 Nov 92 05:33:16 PST
To: cypherpunks@toad.com
Subject: Re: Secure Key exchange
Message-ID: <9211301332.AA10244@cs.gmu.edu>
MIME-Version: 1.0
Content-Type: text/plain



Bob Stratton suggests we hash out ideas on key signing prorocols. Ok, here
is what I do:

I sign keys only when I am certian that the key belongs to the human who
claims to have the name on the key. There are not a lot of keys signed
by me floating arround, maybe six total. My sig does not mean that the
key is not owned by a cop or NSA/CIA/KGB agent (Unlike Edgar's service) 
because I can't tell. So if you care about that stuff, start your
own web of trust with "higher" standards. My sign doesn't mean
that the person is really who they claim to be, I can't tell
that either. I've signed the key of a guy claiming to be "Ray
Kaplan" because I believe that he uses that name reegularly.
But I don't know that his name isn't really Boris Badinov.

You won't find my sig on Phil Zimmermann's key,
even tho that is a popular activity. Phil is a Net/Ether
person to me. My sig means that there is a real person with 
that name. I was at NCSC and exchanged keys there. I'll be
at CFP-3 and exchange keys there too. And if you are in my
area, (suburban Wash DC) we can meet and exchange keys.

I see no reason to hurry. A slowly growing web of trust that
is strong is far more useful than an exploding web of trash.

Pat

Pat Farrell,      Grad Student                       pfarrell@cs.gmu.edu
Department of Computer Science, George Mason University, Fairfax, VA
PGP key available via finger or request           #include standard.disclaimer
Write PKP. Offer money for a personal use license for RSA.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 30 Nov 92 06:10:54 PST
To: marc@mit.edu
Subject: thoughts on digital cash
In-Reply-To: <9211292207.AA22455@deathtongue.MIT.EDU>
Message-ID: <9211301400.AA05557@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Marc Horowitz <marc@mit.edu>

>** Anonymity in banking is a well-known concept.  If I transfer money
>from my numbered swiss bank account to your numbered swiss bank
>account, nobody knows anything, except who the bank is.

Such accounts do not exist in Switzerland -- there is no such thing as
a Swiss account for which the bank does not possess information on who
the account holder is. Such things may have existed at one point --
but emphatically do not exist today. There are a few such things in
existance in odd corners of the world -- but they aren't well
publicized.

>** Legality of starting our own anonymous electronic bank: what do the
>laws say, anyway?  As long as I pay taxes on any profit, I can form a
>sole proprietorship to freely buy and sell purple widgets with very
>little government interaction.  Would it still be legal if I got a
>whole lot of people to accept purple widgets instead of cash?  Would
>it be legal if we called it "digital purple widgets" instead of
>"digital cash"?

The law is a slippery thing -- however, anonymous bank accounts, no
matter what you call them, are almost certainly illegal in the United
States. Most computer people don't seem to understand that the law is
interpreted not by a computer but by humans -- and they won't care
what "hacks" you use. If it smells like a bank, they will
likely convict you if it comes to that point.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: John W Noerenberg <jwn2@qualcomm.com>
Date: Mon, 30 Nov 92 09:07:42 PST
To: tony@morgan.demon.co.uk
Subject: Re: The Cypherpunks Mail Project
Message-ID: <9211301706.AA27590@harvey>
MIME-Version: 1.0
Content-Type: text/plain


At  8:07 PM 11/25/92 +0000, Tony Kidson wrote:
>
>I'd like to chip in here, in my _very_ newbie way, that not 
>everybody is running a unix system with the ability to pipe 
>things between processes in so facile a manner.

Good point.  My vision for the Mac is to have a PGP service with an
AppleEvent suite defined so that any other AE-aware program can use the
services.  This isn't trivial, but it is the right thing to do, imho :-).

john noerenberg
jwn2@qualcomm.com
noerenberg.j (Applelink)
===========================================================
Do not uselessly lament your luck that is giving way, your work that has
failed, your life's plans that have all ended in despair.  Like a man long
prepared, like a man of courage, bid her farewell, the Alexandria that
leaves you.
-- "The God Abandons Anthony", Constantine Peter Cavafy [1911]
===========================================================





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Sun, 29 Nov 92 14:20:56 PST
To: cypherpunks@toad.com
Subject: Secure PK swapping.. what are the methods?
Message-ID: <9211292219.AA28149@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


Since Im not sure this got through to the list last time I'll resend. 
Certainly I havent had any pointers to where to find the information I
need....


------------------------------------------------------------------------
Below is a letter Ive sent to a person designing a communications system
similar to IRC but designed with the ability to be anonymous and as secure
as possible. Further details will be announced soon when it's stable.


--------------------Begin letter----------Begin letter-------------------

Before you get too involved with the client in the comm system I was thinking
of a way of having secure privmsgs, two forms depending on how open one chose
to be:

Messages are exchanged via UDP to hide from the netstat junkies...

When someone does a msg the first time and the client doesnt know about
that user it queries the server to either get a hostname/port pair for
that user and/or a public key. The data is then stored in an internal
attribute bank.

   Format of a private message:

   ._________________________________________________________.
   | Nickname Plaintext     |  dest IP    |  dest udp port   |
   | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= |
   | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= |
   | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= |
   `---------------------------------------------------------'
   [Return host/port/public key are encrypted into the PGP? message]
   The above message is then sent to the delivery module of the client.

   The above host and port are either the recipeints or the server's depending
   on what type of message is being sent. Thus the same message can go to the
   server or the recipient direct per se:

1) Using the hostname/port + public key for that user the sender's client
   encrypts the message and udp transmits a message to that port on the other
   users host. That remote client has set up a socket to listen on that udp
   port for messages. The remote client unpacks the message with it's private 
   key and extracts the message, a reply host and port and the senders public
   key. He can then reply to the sender and they both can talk without
   loading down the server. Plus, unless someone is logging the ethernet,
   no one can ascetain wether they are talking. There is only the initial
   request of the users public key from the server which each client sends
   in automatically when it connects. You might also have an option in the
   client to auto download a block/all of the users nicks and their keys so 
   no-one can detect the initial query of a user.

2) The other, differently secure :), form is because the server has been told
   to hide the users username + hostname from the /who information. All there
   exists for that person is a nickname and a public key. The senders client
   gets individually/block downloads the key he wants and proceeds to udp
   a message to the server which has the udp port and hostname of the
   recipient as normal from the client connect. It acts as IRC does now, as
   a middle man for messages. Less secure because the server admin can 
   ascetain that there is a message being sent between the two people and
   also he can slip in his *OWN* keys to basically grab and decipher messages
   between the two parties. i.e he sends his own key to the sender and
   decrypts the incoming message and then sends the message out to the
   recipient using their encryption key. neither user could tell there was a
   switch in between. (There are schemes to get past this however).

Both ways have their flaws because you are relying on the non-hackedness of
the server to give you the right keys and hostnames and ports. A bad admin
could easily, knowing enough about coding, disrupt the entire process if we
didnt from the start ensure the right protocols were used. It has to be done
right the first time or not at all.

I'll echo this letter to a cryptography mailing list to ask for details of
schemes that will allow each user to know they have a valid, secure public
key of the other.

One possible solution would be to do a mass query of all the online servers
at once and if they didnt report the same keys sound a Real Big Alarm (tm).
Maybe an automatom could sit there randomly checking keys :) (Can hear the
cries of "No Bots.. No Bots" now :). (Note this allows *someone* to know your
doing a query for a user... that may or may not bother the sender/recipient.
Doing a block transfer from all the servers at once isnt net.nice)

Comments?

------------------End of Letter----------------End of Letter----------------

Now what Im curious about is any other methods of secure key exchange where
the exchange mid point may be lying about the keys, the hosts and the ports.
Assume each person knows the others 'style' etc. How does one get the real 
keys to each other with an unreliable "medium"? (It might slip in it's PK).
Assume that they havent previously organised a key exchange.

Replies to me or the list.. (but not both please.. my mbox is busy enuff :)

Mark
mark@coombs.anu.edu.au






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Mon, 30 Nov 92 10:03:02 PST
To: uunet!intercon.com!strat@uunet.UU.NET
Subject: Secure key exchange I have to echo Phil's comments here. One of the things that might be worth a few minutes is for this group to hash out (pun intended) a set of guidelines for "when it's o.k. to sign a key". I have been
In-Reply-To: <9211300930.AA00855@intercon.com>
Message-ID: <9211301720.AA19058@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain



An excellent suggestion.  Can you start writing such a thing? (This is
not a facetious request).  I imagine there will be two or three
strategies for approving a key, and if we write them up well, we will
be able to ask people which protocol they have engaged in:

1) Only people I know personally and whose keys I receive in person.

2...

n) Any key received throuhg any medium.

This could have lots of educational value.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 30 Nov 92 09:22:03 PST
To: cypherpunks@toad.com
Subject: Secure key exchange
In-Reply-To: <PBgyuB5w165w@spectrx.saigon.com>
Message-ID: <9211301721.AA17060@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>There is no secure method of exchanging public keys using only the
>net.  [spoofing, etc.]

As mentioned by Hal, the new PGP 2.1 (imminent) has a feature to
create an hash or a public key which can be read over the telephone to
make sure that a key transmitted electronically has not been altered
in transmission.

>[long business description deleted]

There's really no need for a physical authentication service with the
telephone verfication ability.

>Plan B is to exchange/verify public keys face-to-face at parties,

There is just such a plan underway to have a PGP key exchange table at
Usenix in January.

>I have printed up business-card
>size copies of *fragments* of my public keys with the 6-hex-digit
>"Key ID".  

What could easily be printed is the hash function of the key.  That
would be even harder to duplicate.

Eric







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 30 Nov 92 09:37:45 PST
To: cypherpunks@toad.com
Subject: Secure Key exchange
In-Reply-To: <9211301332.AA10244@cs.gmu.edu>
Message-ID: <9211301737.AA17617@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Pat Farrell write:
>A slowly growing web of trust that
>is strong is far more useful than an exploding web of trash.

I urge everybody to go out and quote this!

It's a great aphorism.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 30 Nov 92 09:43:34 PST
To: cypherpunks@toad.com
Subject: thoughts on digital cash
In-Reply-To: <9211301400.AA05557@newsu.shearson.com>
Message-ID: <9211301743.AA17881@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



>>** Legality of starting our own anonymous electronic bank: what do the
>>laws say, anyway?

Perry write:

>The law is a slippery thing -- however, anonymous bank accounts, no
>matter what you call them, are almost certainly illegal in the United
>States. 

OK, Perry, time to quote sources.  Exactly what laws _do_ prohibit
such bank accounts?

>Most computer people don't seem to understand that the law is
>interpreted not by a computer but by humans -- and they won't care
>what "hacks" you use. If it smells like a bank, they will
>likely convict you if it comes to that point.

Most political dissidents don't seem to understand that the law is
interpreted accurately, for the most part.  There exist clear
statutory definitions on what a bank is.  If you don't meet those
criteria, you're not a bank.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: lasterm@ohm.ee.utulsa.edu (Mike Laster (664-5510))
Date: Mon, 30 Nov 92 08:13:16 PST
To: ncselxsi!drzaphod@ncselxsi.netcom.com
Subject: RE: PGP on local machine (was Re: MacPGP)
Message-ID: <9211301610.AA05451@ohm.ee.utulsa.edu>
MIME-Version: 1.0
Content-Type: text/plain


folders


a




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Mon, 30 Nov 92 11:19:02 PST
To: cypherpunks@toad.com
Subject: Re: Electronic Banking
Message-ID: <9211301830.AA23870@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Eric Hughes points out that the blind signatures used to provide
anonymity in Chaum's digital cash schemes are patented (by Chaum
himself).  This is a problem for an official, legal, profit-making
business which wants to engage in electronic banking.

However, such a business would face many other problems.  Chaum's
digital cash system could be construed as using the RSA algorithms,
since it is in effect an RSA signature which makes the cash
unforgeable.  So a license for RSA would have to be obtained as well.
(RSA licensing would also be needed for secure communication between
the bank and its customers.)

In addition, the acceptable use policies of NSFNET, which would
probably have to be involved in most communications with the bank,
are inconsistent with this kind of commercial activity, from what I
understand.  I believe new policies are in the works to allow
commercial activities on the net, but these again will involve
licensing costs.

There is also the question of the legality of private cash in any
form, electronic or otherwise.  Nobody seems to have hard evidence on
this.  On the one hand, people can legally exchange certain types of
securities, and they could perform services for each other in return
for such exchanges.  This is legal, but they are supposed to report
the income on their tax returns.  Our digital cash would seem to fit
this model.  (But are such securities transfers as untraceable as
digital cash?  Perhaps not.)

On the other hand, I read several years ago that casino chips in Las
Vegas were starting to be used as cash substitutes, but that the
government cracked down on this practice.  Perhaps this was too
conducive to money laundering, especially with the reputed underworld
activity in that city.

I do think, though, that an informal digital cash system, presented as
a research project or an educational game, would be able to slip
between the cracks of the legal system, much as PGP has done.  And I
think this presentation would be legitimate.  Digital cash is new
(actually, nonexistant, as far as I know), and any use of it would by
its very nature be research and be educational.

I would suggest that anyone who proposes to implement such a game
might want to consider releasing it anonymously (actually,
pseudonymously).  Sign the release with a PGP or RIPEM key, and let
that be your pseudonym.  Let people post messages to alt.security.pgp
or some other newsgroup to discuss it, so that you can read them
without revealing yourself, as proposed by Yanek.  Post your replies
anonymously using our remailers.

This way there won't be a single-point target for anyone wishing to
punish users of the game.

Hal
74076.1041@compuserve.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Mon, 30 Nov 92 11:15:21 PST
To: uunet!us.oracle.com!rchilder@uunet.UU.NET
Subject: credibility and banking It seems to me that there are many parallels between this state of affairs and that which prevailed in the American West of the 1800s, with respect to banking .... there were no agencies insuring deposits, and only the rep- -utation of the bank's president - usually a leader of the community - was guarantee upon the funds. Bank robberies were not uncommon, depositors were
In-Reply-To: <9211290400.AA00660@rchilder.us.oracle.com>
Message-ID: <9211301831.AA19785@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


Our mechanisms for estimating credibility of a guarantor partly assume
that life can be made difficult for the guarantor if they renege.
Those intuitions are often completely wrong if the guarantor is
anonymous.  That's the main point of what I was saying.

	 few, runs on the bank, I speculate, may not have been unknown in those cir-
	 -cumstances where the community of bank depositors lost confidence in the
	 bank or its officers.

My understanding of the history of banking is that there are ZERO
documented cases of runs on banks before the gov't started mucking
with the banking industry.  They started that mucking based on some
economists projection that such a run could happen, so the gov't had
to protect the pipul from it.

	 It would be interesting to further study the origins of banking, as I expect
	 such a study would provide many such parallels by which the case for digi-
	 -tized banking could be made stronger ...

It also has strong arguments for free banking, which is consequence of
cryptographic electronic banking.

dean





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: bwebster@pages.com (Bruce F. Webster)
Date: Mon, 30 Nov 92 11:34:34 PST
To: cypherpunks@toad.com
Subject: Re: Paranoia and Cypherpunks
Message-ID: <9211301900.AA14307@pages.com>
MIME-Version: 1.0
Content-Type: text/plain



> (Surely John Gilmore's lawsuit to get some critical crypto papers
> declassified has already "angered" the folks at NSA. Are we to 

> censure John for stirring up trouble? 


Buy him a really nice dinner would be a more appropriate response.  
:-) 'Way to go, John!   ..bruce..

---------------------------------------------------------------------
Bruce F. Webster        |  We hackers linger by our leading edge
Chief Technical Officer |  Forgetting what is pending in the cache
Pages Software Inc      |  Till practice hurtles past us,
bwebster@pages.com      |    and we crash.    -- Jeff Duntemann
---------------------------------------------------------------------




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fen@genmagic.com (Fen Labalme)
Date: Mon, 30 Nov 92 12:19:33 PST
To: cypherpunks@toad.com
Subject: Re: remailers
Message-ID: <9211301903.AB08401@>
MIME-Version: 1.0
Content-Type: text/plain


[ Marc Horowitz <marc@MIT.EDU> writes: ]
>People who want to use remailers don't necessarily have the access to
>turn their site into one.  Far more people use email than are
>sysadmins, or friendly with one.

[ mark@coombs.anu.edu.au (Mark) agrees: ]
>What if for instance the user is sending from a student account or some
>other limited system (such as a PC) and they either arent allowed to run
>nohupped unattended processes or are unable to. Will you deny them the use
>of your remailer simply because they cant, or havent the technical knowledge
>on how to, install their own remailer? That sounds a bit odd to me....

First, things are changing.  More and more people are owning their own
machines and setting up their own mail.  Heck, I'm planning on having my
own internet node at home!

Second, we need to proliferate remailers.  Get the students running the
system to install the code (perhaps for credit!).  Or, if you're at a
company, explain to the sysadmin that you need to have access to information
that is only availble from sources on the other side of remailers, or,
perhaps more generally, just indicate that you need connectivity and that
not being a remailer cuts down on the number of sites that you can connect
to.

Finally, perhaps a "student" rating can be added (in addition to "free"
and "reputation-based").

Keeping track of the reputations of remailers is a first step to being
able to keep track of the reputations of signatures (whether real or
pseudonymous).  The next step is the active filtering based on such info.

Fen





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: John W Noerenberg <jwn2@qualcomm.com>
Date: Mon, 30 Nov 92 11:54:14 PST
To: crunch@netcom.com (John Draper)
Subject: Re: Classified info and other stuff.
Message-ID: <9211301953.AA02873@harvey>
MIME-Version: 1.0
Content-Type: text/plain


At 10:44 PM 11/27/92 -0800, John Draper wrote:
>Oh,  By the way,   numerious complaints have been said about the way that
>the Mac PGP was stuffed when posted onto "umich'.    I will be pushing for
>releasing it stuffed with a self extracting archive instead.   I also had
>problems and lost significant time acquiring the new stuffit in order to
>extract it.
>
>John D.

Aladdin makes a freely available unstuffer which reads all their current
formats, including self-extracting archives.  I found it on their applelink
bboard.

john noerenberg
jwn2@qualcomm.com
noerenberg.j (Applelink)
===========================================================
Do not uselessly lament your luck that is giving way, your work that has
failed, your life's plans that have all ended in despair.  Like a man long
prepared, like a man of courage, bid her farewell, the Alexandria that
leaves you.
-- "The God Abandons Anthony", Constantine Peter Cavafy [1911]
===========================================================





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: phr@napa.Telebit.COM (Paul Rubin)
Date: Mon, 30 Nov 92 11:54:35 PST
To: eichin@cygnus.com
Subject: Secure Key exchange
In-Reply-To: <9211301925.AA29778@tweedledumber.cygnus.com>
Message-ID: <9211301954.AA13674@napa.TELEBIT.COM>
MIME-Version: 1.0
Content-Type: text/plain


	    I have at this point signed keys of 6 people (the first three
    over dinner at a chinese restaurant -- this didn't start a trend,
    unfortunately :-) I haven't signed John Gilmore's key (even though I
    work for him) since I haven't actually seen him in person, though I
    may get a chance to when I'm in California next week -- this will
    create a link between east-coast and west-coast signatures, though
    possibly not the first.

If you meet someone claiming to be John Gilmore,
how will you know he's not an impostor?




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: deboni@diego.llnl.gov (Tom DeBoni)
Date: Mon, 30 Nov 92 12:53:42 PST
To: cypherpunks@toad.com
Subject: tutorial needed
Message-ID: <9211302051.AA25066@diego.llnl.gov>
MIME-Version: 1.0
Content-Type: text/plain


Howdy! I'm in need of a tutorial text that will bring me up to date on
the current methods and terminology in the crypto arena. Any and all
suggetions are welcome, and since this is probably an old and tired 
topic on this list, feel free to mail them to me directly.

Thanks!
Tom deBoni
deboni@diego.llnl.gov




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 30 Nov 92 11:49:21 PST
To: hughes@soda.berkeley.edu
Subject: Secure key exchange
In-Reply-To: <9211301721.AA17060@soda.berkeley.edu>
Message-ID: <9211301806.AA08378@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Eric Hughes <hughes@soda.berkeley.edu>

>>There is no secure method of exchanging public keys using only the
>>net.  [spoofing, etc.]

>As mentioned by Hal, the new PGP 2.1 (imminent) has a feature to
>create an hash or a public key which can be read over the telephone to
>make sure that a key transmitted electronically has not been altered
>in transmission.

Just to point out, though, this is not foolproof. A good impressionist
can fool people, especially if they are extremely skilled. A person
with Rich Little's or Peter Sellers' level of skill can sound
astonishingly like the original person (although a sound spectrograph
isn't fooled, other humans can be).

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Date: Mon, 30 Nov 92 10:37:21 PST
To: pfarrell@cs.gmu.edu
Subject: Re: Secure Key exchange
In-Reply-To: <9211301332.AA10244@cs.gmu.edu>
Message-ID: <9211301836.AA20482@tsx-11.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


   Date: Mon, 30 Nov 92 08:32:45 EST
   From: pfarrell@cs.gmu.edu (Pat Farrell)

   I sign keys only when I am certian that the key belongs to the human who
   claims to have the name on the key. There are not a lot of keys signed
   by me floating arround, maybe six total.....

Ah, but how do we know that it's really you making this statement, and
not some evil NSA spoofer?  What people need to do is to make their
key-signinging policies available _signed_ with their private key; that
way at least we would know that the entity signing the keys and the
entity claiming that this is its policy are the same.  This helps, but
we would then still need to trust that the entity is telling the truth
insofar as its key-signing policy is concerned.

						- Ted




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pfarrell@cs.gmu.edu (Pat Farrell)
Date: Mon, 30 Nov 92 11:11:12 PST
To: tytso@ATHENA.MIT.EDU
Subject: Re: Secure Key exchange
Message-ID: <9211301910.AA11750@cs.gmu.edu>
MIME-Version: 1.0
Content-Type: text/plain


	tytso@ATHENA.MIT.EDU (Theodore Ts'o) wrote:
	  quoting: pfarrell@cs.gmu.edu (Pat Farrell)
	   I sign keys only when I am certian that the key belongs to 
           the human who claims to have the name on the key. There 
           are not a lot of keys signed by me floating arround, maybe 
           six total.....
  tt> 
  tt> Ah, but how do we know that it's really you making this statement, and
  tt> not some evil NSA spoofer?  What people need to do is to make their
  tt> key-signinging policies available _signed_ with their private key; that
  tt> way at least we would know that the entity signing the keys and the
  tt> entity claiming that this is its policy are the same.  
Exellent point. I'll put a signed statement of my policy in my
.plan. It won't add many characters, and anyone can find it by
fingering me. (and I've never claimed I don't work for
NSA/CIA/...)

  tt>         This helps, but
  tt> we would then still need to trust that the entity is telling the truth
  tt> insofar as its key-signing policy is concerned.
I can't solve this one so easily. I have two ideas that can
help:
	1. change PGP in future versions (starting with 2.1?)
so it doesn't ask for confirmation every time a key is added
to the ring. Make the user do an active action, rather than a
half-asleep y<cr> to sign a key.

	2. store a comment in my secret ring that is captured
each time I sign a key. Thus I could store the
"reason/justification" for the signature to jog my memory. I
know whose key's I've signed now, but as the number gets bigger, then
I'll need a memory aid. I suggest the secret ring, as I share
my public ring, and don't think that why I chose to sign a key
should be generally available. If this were supported, you
could then send me a msg asking "why did you sign John Doe's
key?" You would have to compare my answer to my published
policy and make your own judgement as to whether I follow it.

I could keep track of this manually, and should. But PGP
already requires me to have a lot of files arround.

Pat

Pat Farrell,      Grad Student                       pfarrell@cs.gmu.edu
Department of Computer Science, George Mason University, Fairfax, VA
PGP key available via finger or request           #include standard.disclaimer
Write PKP. Offer money for a personal use license for RSA.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 30 Nov 92 14:14:20 PST
To: cypherpunks@toad.com
Subject: thoughts on digital cash
In-Reply-To: <9211301957.AA10429@newsu.shearson.com>
Message-ID: <9211302214.AA08418@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Perry writes:

>If you take deposits and allow people to write drafts against those
>deposits you are going to fall under the commercial banking or
>securities laws no matter what you do, Eric. 

The definition of a bank is an institution that accepts demand
deposits.

From Black's Law Dictionary:

Demand deposits.  Any bank deposit which the depositor may demand
(withdraw) at any time in contrast to time deposit which requires
depositor to wait the specified time before withdrawing or pay a
penalty for early withdrawal.  Funds accepted by bank subject to
immediate withdrawal; such represent largest element in money supply
of the United States.

Certain mutual funds which have checks available to them do not fall
under this classification.  Such a mutual fund might be said to have
deposits, but they are not demand deposits.  You can't get them
whenever you like.  The fine print of such aggreements states that the
mutual fund company does not have to honor the check for up to thirty
days, typically.  Because of the time delay, such deposits are not
payable on "demand."

Mutual funds, though, since they are backed by securities, do fall
under securities law.  

Again, from Black's:

For purposes of the Securities Act of 1933 and the Securities Exchange
Act of 1934, the term "security" embraces all investment contracts,
and the test is whether the investment is made in a common enterprise
which is premised upon the reasonable expectation of profits solely
from the managerial or entrepreneurial efforts of others; such test
contains three elements: the investment of money; a common enterprise;
and profits or returns derived soleley from efforts of others.

I merely pointed out that if you're not a bank, you're not under
banking regulation.  This does not preclude regulation under other
laws.

Eric





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Mon, 30 Nov 92 11:25:34 PST
To: pfarrell@cs.gmu.edu
Subject: re: Secure Key exchange
In-Reply-To: <9211301332.AA10244@cs.gmu.edu>
Message-ID: <9211301925.AA29778@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


>> I see no reason to hurry. A slowly growing web of trust that
>> is strong is far more useful than an exploding web of trash.
	precisely. I only sign keys when I've met the person
physically, and had them tell me that yes, they have a PGP key, and
yes, here are the lower bits (the keyid.) (The latter is a little
weak, I look forward to the MD5 output version...) I keep keyid's in
my "little black book" as well as my online keyring.
	Also, because keys are a reasonable "proof" that one is using
PGP, some people will only release their "public" keys to people they
will correspond with anyhow. (At least one key on the recent
cypherpunks key list was in that category.) 
	I have at this point signed keys of 6 people (the first three
over dinner at a chinese restaurant -- this didn't start a trend,
unfortunately :-) I haven't signed John Gilmore's key (even though I
work for him) since I haven't actually seen him in person, though I
may get a chance to when I'm in California next week -- this will
create a link between east-coast and west-coast signatures, though
possibly not the first.
				_Mark_ <eichin@athena.mit.edu>
				MIT Student Information Processing Board
				Cygnus Support <eichin@cygnus.com>





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Mon, 30 Nov 92 11:37:42 PST
To: tytso@ATHENA.MIT.EDU
Subject: re: Secure Key exchange
In-Reply-To: <9211301836.AA20482@tsx-11.MIT.EDU>
Message-ID: <9211301937.AA29781@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


<tytso@ATHENA.MIT.EDU> allegedly (:-) writes:
>> key-signinging policies available _signed_ with their private key; that
	I noticed in the pgp docs that there is a "signature
classification field" which has a (rather small) set of reserved
values, only one of which is actually implemented:
	10 -	Key certification, generic.  Only version of key
		certification supported by PGP 2.0.
		Material signed is public key pkt and User ID pkt.
	11 -	Key certification, persona.  No attempt made at all
		to identify the user with a real name.
		Material signed is public key pkt and User ID pkt.
	12 -	Key certification, casual identification.  Some
		casual attempt made to identify user with his name.
		Material signed is public key pkt and User ID pkt.
	13 -	Key certification, positive ID.  Heavy-duty
		identification efforts, photo ID, direct contact
		with personal friend, etc.
		Material signed is public key pkt and User ID pkt.

>> we would then still need to trust that the entity is telling the truth

I think we probably need a similar "web" certifying operational
procedures. (That is, I believe, one thing that the PEM hierarchy
claims to provide -- the institutional signature providers are
auditted, etc. to guarantee that they provide the claimed level of
security.) Some people trust my signatures more than other signatures
because I'm already known to be somewhat "paranoid" w.r.t. security
matters...
				_Mark_ <eichin@athena.mit.edu>
				MIT Student Information Processing Board
				Cygnus Support <eichin@cygnus.com>




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 30 Nov 92 14:41:53 PST
To: cypherpunks@toad.com
Subject: thoughts on digital cash
In-Reply-To: <9211301957.AA10429@newsu.shearson.com>
Message-ID: <9211302241.AA00770@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


>However, I'm so certain that the law in the U.S. requires
>that the bank have full information on the holders of all accounts
>that I'm willing to bet $150 right now with anyone who believes
>otherwise. 

You've certainly showed us that you believe this Perry, but otherwise
this statement contains no educational content.  This, to me, sounds
like a grown-up version of "Is so!!!" backed up by "My bank account
can beat up your bank account!"

>[...] ID be presented when you open an account (I know that this is
>now routine practice, although its possible that its only implied
>from the standards used to determine non-compliance rather than
>directly required by the law.)

I'd really like to know if ID is required or not, for one, because
that seems to affect the banks liability vis-a-vis presentation of
false credentials.

You made a claim of fact.  I'm asking for you to provide a reference
in support of your claim.  Simple rational discourse.

>[...] you are going to fall under the commercial banking or
>securities laws no matter what you do, Eric. I'm sorry that you don't
>like this, but its the truth.

Now you're putting words into my mouth.  I made no judgement as to
whether I thought this was a good state of affairs.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pfarrell@cs.gmu.edu (Pat Farrell)
Date: Mon, 30 Nov 92 11:44:28 PST
To: cypherpunks@toad.com
Subject: my key signing policy, signed
Message-ID: <9211301943.AA11949@cs.gmu.edu>
MIME-Version: 1.0
Content-Type: text/plain


As suggested, here is a PGP signed copy of my policy.
It and my public key is available via finger

-----BEGIN PGP MESSAGE-----
Version: 2.0

owGVVL9rFEEUToKKnm5nIWl8YBPxcjGJIkERlaBoQAKayiLM7b69G252Zp2ZvXOx
FTGI/gmKdgER7PwBFnY2YiWCWIggImihqIUSfW/2Ek8E0eVgj5n343vf971dGloY
WT+8azST28+Mdq+aj1eGh9+/HBm6e3OufHxh6fu968+e7vi05cGj+5e+fLt96/Om
pdnl84cfPpk5sfD6xcSG6MfbrRdXGl8vb96/be7DtSMv36y0b8w+f3dned0rv9HJ
ls6V0EP0wP8/J00XsyZamN5dh8mZmamodrotHdAvKyE3SsYlpMYC95G6BfPH5qGD
pasDpinGXnYRUmsyDk+ldR4Kh2BSDmxEteOQiRLittAtBOlBavBtyih8YbEOQifQ
k0qtRnju3e/qvPCYofacoakWVzNalQFLAAE9uoHjsNhEJbGLixQqQjxf8xCx0d4a
pTCBZhkucrTO6KjWaxsCqkWGE9Q7UcjhRq8mN6isxbOFtIRWxDjuzTi/aQIqmBQ0
OQVTYlTDc330NHXeLp2MhQrwuEZbEEEMmBD4nqlgjxHjWqI9FIusYWxrZyCCqTeZ
cHCY8Oo6HNg3tXd6X2Nycs/0odhkORFru9igvwdBpJ5EEzyNNAl3ZhwedUJ9BgGh
jm2ZezrN0DnRQlLOaSEVCSNVpUDeNhqBUCuCzCz36Vxlk4kKuOnckAe8gXm64FRG
TDy5vLKCKoPmQVJtgKPRDuolqVrh12iqB265YHgPAI9qv1EJY8EabKYmQiJdB8iU
uaD5d/atEZjORILcWXjyTu65cpcoSstfzqgMQKBp3hIUtsLb9LSLanzPlliLJu8q
ITNWMvmjVElFWoUSlvLZ9QEip0c18nleNMnH/UxtPHS06YFMq0xBvqoiQvuesR1e
r4IEJF3JWc4VGZK7uN7fisTWmA6JGpucpc15NR3GFkmgFm0Pb6qPK11FVi1QjNbT
INzwt4Wp9HXM2gBTtCk8nuOzPp6o9q8fGDbKUWEtKvXvSaeqfWG3rH5wgsg/AQ==
=mxji
-----END PGP MESSAGE-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tom.jennings@f111.n125.z1.FIDONET.ORG (tom jennings)
Date: Mon, 30 Nov 92 13:58:28 PST
To: cypherpunks@toad.com
Subject: USSC Cases Available
Message-ID: <3939.2B1A8DA6@fidogate.FIDONET.ORG>
MIME-Version: 1.0
Content-Type: text/plain



Cross posted from a local net 125 echo... net access not availble for
this system.


       -----------------------------------------------
       | To All Sysops -- You might want to leave an |
       | announcement advising your users of the     |
       | following. -={lsg}=-                        |
       -----------------------------------------------

       USSC CASES & Selected Other Legal Decisions Available

The PC GFX Exchange BBS in San Francisco has begun building a
collection of US Supreme Court and selected legal decisions (eg.,
Cubby v. CompuServe).  The files are PKZIPed and, after their
initial upload, will eventually be moved into the board's file
directory #64 (Legal & USSC Case Files).

The BBS can be reached at the following numbers.  

415-337-5416 HST144/v.32bis (public line)
415-337-5599 HST168/v.32bis (downloading for subscribers only)
415-337-6846 HST144         (public line)
415-337-6849 HST168/v.32bis (public line)

While the board is an RBBSNet node, regretfully, FREQs are not
currently available.

PC GFX also carries the FidoNet LAW Echo as well as the LEGAL echos
from SmartNet and ILink.

A special note of deep appreciation to Mike Riddle and Alec Grynspan
for their generous contributions to the file base.

               -=<Lester Garrett, PC GFX Co-SysOp>=-

--- msgedsq 2.1
 * Origin: -={The Lyceum}=- San Francisco, CA (1:125/101)
--  
tom jennings - via FidoNet node 1:125/555
    UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings
INTERNET - tom.jennings@f111.n125.z1.FIDONET.ORG




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wcs@anchor.ho.att.com (Bill Stewart)
Date: Mon, 30 Nov 92 11:45:58 PST
To: cypherpunks@toad.com
Subject: cypherpunks mailing list structure
Message-ID: <9211301944.AA03295@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text


It's nice to have cypherpunks-announce existing.  A couple questions:
- will all the cypherpunks-announce traffic be gatewayed to cypherpunks?
  (alternatively, have all the cypherpunks subscribers been added to -announce?)
- will the new list be announced to sci.crypt, etc.? - we've already lost a
  number of subscribers from cypherpunks due to volume, so folks may have
  missed the announcement.

I've been getting swamped by the number of postings coming in through the day,
and we seem to have been losing a lot of people.  It's getting hard to
find my "real" mail in the clutter.
An alternative structure, which libernet uses, is to have both batch and
reflection subscriptions - batch folks get one digest a day, (produced 
automatically rather than by-hand as with some digest), which has the
articles in alphabetic-by-Subject order to provide some continuity.
Would it be possible for cypherpunks to do the same?
		Thanks;  Bill Stewart, somewhere over New Jersey.



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pfarrell@cs.gmu.edu (Pat Farrell)
Date: Mon, 30 Nov 92 11:47:51 PST
To: cypherpunks@toad.com
Subject: My key policy signed.
Message-ID: <9211301947.AA11983@cs.gmu.edu>
MIME-Version: 1.0
Content-Type: text/plain


As suggested, here is my key policy signed (not encrypted).
It has minor rewordings from my clear text posting of this morning.
It and my public key are available via finger.
-----BEGIN PGP MESSAGE-----
Version: 2.0

owGVVL9rFEEUToKKnm5nIWl8YBPxcjGJIkERlaBoQAKayiLM7b69G252Zp2ZvXOx
FTGI/gmKdgER7PwBFnY2YiWCWIggImihqIUSfW/2Ek8E0eVgj5n343vf971dGloY
WT+8azST28+Mdq+aj1eGh9+/HBm6e3OufHxh6fu968+e7vi05cGj+5e+fLt96/Om
pdnl84cfPpk5sfD6xcSG6MfbrRdXGl8vb96/be7DtSMv36y0b8w+f3dned0rv9HJ
ls6V0EP0wP8/J00XsyZamN5dh8mZmamodrotHdAvKyE3SsYlpMYC95G6BfPH5qGD
pasDpinGXnYRUmsyDk+ldR4Kh2BSDmxEteOQiRLittAtBOlBavBtyih8YbEOQifQ
k0qtRnju3e/qvPCYofacoakWVzNalQFLAAE9uoHjsNhEJbGLixQqQjxf8xCx0d4a
pTCBZhkucrTO6KjWaxsCqkWGE9Q7UcjhRq8mN6isxbOFtIRWxDjuzTi/aQIqmBQ0
OQVTYlTDc330NHXeLp2MhQrwuEZbEEEMmBD4nqlgjxHjWqI9FIusYWxrZyCCqTeZ
cHCY8Oo6HNg3tXd6X2Nycs/0odhkORFru9igvwdBpJ5EEzyNNAl3ZhwedUJ9BgGh
jm2ZezrN0DnRQlLOaSEVCSNVpUDeNhqBUCuCzCz36Vxlk4kKuOnckAe8gXm64FRG
TDy5vLKCKoPmQVJtgKPRDuolqVrh12iqB265YHgPAI9qv1EJY8EabKYmQiJdB8iU
uaD5d/atEZjORILcWXjyTu65cpcoSstfzqgMQKBp3hIUtsLb9LSLanzPlliLJu8q
ITNWMvmjVElFWoUSlvLZ9QEip0c18nleNMnH/UxtPHS06YFMq0xBvqoiQvuesR1e
r4IEJF3JWc4VGZK7uN7fisTWmA6JGpucpc15NR3GFkmgFm0Pb6qPK11FVi1QjNbT
INzwt4Wp9HXM2gBTtCk8nuOzPp6o9q8fGDbKUWEtKvXvSaeqfWG3rH5wgsg/AQ==
=mxji
-----END PGP MESSAGE-----

Pat Farrell,      Grad Student                       pfarrell@cs.gmu.edu
Department of Computer Science, George Mason University, Fairfax, VA
PGP key available via finger or request           #include standard.disclaimer
Write PKP. Offer money for a personal use license for RSA.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Mon, 30 Nov 92 15:20:39 PST
To: uunet!anchor.ho.att.com!wcs@uunet.UU.NET
Subject: cypherpunks mailing list structure
In-Reply-To: <9211301944.AA03295@anchor.ho.att.com>
Message-ID: <9211302248.AA21643@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


I would note that even the current remailers can double as
mail-sorters to sort your crypto mail into different bins.  This lets
you just peruse them once a day, and keeps your higher priority mail
separate.  I like this solution because more people will then have
built-in remailers.  Right now it only is set up for UNIX, but the
ideas can be reproduced elsewhere.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 30 Nov 92 12:38:24 PST
To: hughes@soda.berkeley.edu
Subject: thoughts on digital cash
In-Reply-To: <9211301743.AA17881@soda.berkeley.edu>
Message-ID: <9211301957.AA10429@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Eric Hughes <hughes@soda.berkeley.edu>

>>>** Legality of starting our own anonymous electronic bank: what do the
>>>laws say, anyway?

>Perry write:

>>The law is a slippery thing -- however, anonymous bank accounts, no
>>matter what you call them, are almost certainly illegal in the United
>>States. 

>OK, Perry, time to quote sources.  Exactly what laws _do_ prohibit
>such bank accounts?

I know securities law much better than commercial banking law -- I
can't quote commercial banking law or the UCC for the most part, so
I've got no idea precisely where in the codes such accounts are
prohibited.  However, I'm so certain that the law in the U.S. requires
that the bank have full information on the holders of all accounts
that I'm willing to bet $150 right now with anyone who believes
otherwise. The law not only requires that the bank know who you are,
but may even require that ID be presented when you open an account (I
know that this is now routine practice, although its possible that its
only implied from the standards used to determine non-compliance
rather than directly required by the law.) I don't have any incentive
to find the precise place in the books where it says you can't have an
anonymous account in the US, but for a few hundred bucks in easy money
I'd find it fairly quickly. If you don't believe me, well, have fun.

>>Most computer people don't seem to understand that the law is
>>interpreted not by a computer but by humans -- and they won't care
>>what "hacks" you use. If it smells like a bank, they will
>>likely convict you if it comes to that point.

>Most political dissidents don't seem to understand that the law is
>interpreted accurately, for the most part.  There exist clear
>statutory definitions on what a bank is.  If you don't meet those
>criteria, you're not a bank.

If you take deposits and allow people to write drafts against those
deposits you are going to fall under the commercial banking or
securities laws no matter what you do, Eric. I'm sorry that you don't
like this, but its the truth. The best you can hope for is to be
classified as a mutual fund or the like and not as a commercial bank
-- in which case the reporting requirements are just as tight and you
fall under the even more restrictive securities laws. The securities
laws are EXTRAORDINARILY tight when it comes to reporting. Other than
brokerages holding securities in street name, nominee and other
anonymous arangements of any sort are not merely prohibited under the
securities laws but actual criminal offenses.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Mon, 30 Nov 92 15:04:22 PST
To: cypherpunks@toad.com
Subject: Electronic Banking
In-Reply-To: <9211301830.AA23870@nano.noname>
Message-ID: <9211302303.AA02723@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Hal mentions all the problems a going concern would have with an
electronic banking: patent on the blind signature, RSA license also
required, acceptable use policy, underlying legality.

>I do think, though, that an informal digital cash system, presented as
>a research project or an educational game, would be able to slip
>between the cracks of the legal system, much as PGP has done.  

I agree.  An experimental money system should be fine, practically
speaking.  There will be no problem if no goods or services change
hands.  If everything is scored in points, then there is no concern
about money at all.

More generally, a digital money system is isomorphic to a conserved
quantity server.  For example, if I were to write a distributed
multi-player simulation game, I could represent conserved quantities
such as fuel and ammunition as the equivalent digital money tokens.
That is, in order to fire, I have to "spend" a bullet.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 30 Nov 92 14:03:15 PST
To: tribble@xanadu.com
Subject: credibility and banking
In-Reply-To: <9211301831.AA19785@xanadu.xanadu.com>
Message-ID: <9211302008.AA10892@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: tribble@xanadu.com (E. Dean Tribble)

>My understanding of the history of banking is that there are ZERO
>documented cases of runs on banks before the gov't started mucking
>with the banking industry.  They started that mucking based on some
>economists projection that such a run could happen, so the gov't had
>to protect the pipul from it.

Not strictly speaking the case -- there were instances of bank runs
under free banking systems, but restriction clauses usually eliminated
these problems immediately. Restriction clauses permitted banks to
briefly suspend payments in gold, with a heavy interest penalty paid
by the bank. Such clauses allowed banks to stop runs, but they could
not be lightly used. In any case, runs were quite infrequent under
free banking systems.

In any case, I believe that digital banknote systems, when they
arrive, will almost certainly involve explicit issuance banks rather
than any sort of anonymous banks. Likely such banks will first appear
offshore and will, at least at first, be nothing more than banks that
accept cryptographically signed electronic mail in the stead of checks
and bank drafts.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Mon, 30 Nov 92 12:09:44 PST
To: phr@napa.Telebit.COM
Subject: Secure Key exchange
In-Reply-To: <9211301954.AA13674@napa.TELEBIT.COM>
Message-ID: <9211302009.AA29816@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


<phr@napa.Telebit.COM> allegedly asks:
>> If you meet someone claiming to be John Gilmore,
>> how will you know he's not an impostor?
	1) I've met him before. (I wouldn't, for example, sign Tim
Jennings' key after meeting him for the first time at a cypherpunks
meeting, since I'd have no other way of identifying him. You, on the
other hand, may be someone I've met before (do you think so?) so I
might...) I've interacted with him to a reasonable extend, both
socially and technically (including one interview with John Markoff.)
	2) He signs my paychecks -- which is "good enough", since the
checks clear :-) 
				_Mark_ <eichin@athena.mit.edu>
				MIT Student Information Processing Board
				Cygnus Support <eichin@cygnus.com>





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Mon, 30 Nov 92 15:45:30 PST
To: pmetzger@shearson.com
Subject: Re: thoughts on digital cash
In-Reply-To: <9211301957.AA10429@newsu.shearson.com>
Message-ID: <9211302344.AA06143@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



We should just write all the software to fully automate the system, get
lightweight hardware for it and some solar panels and launch it into orbit.
Whose jurisdiction is that?

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wcs@anchor.ho.att.com (Bill Stewart)
Date: Mon, 30 Nov 92 14:47:10 PST
To: cypherpunks@toad.com
Subject: Re: Unlabelled PGP messages
Message-ID: <9211302245.AA04980@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text


Hal Finney points out some problems with unlabelled messages,
where the headers don't identify the public key by keyid -
remailers include your email address, while newsgroups / broadcasts
might have a LOT of articles, such that decrypting them to see if they're
for you would be impractically slow.  Some techniques that may help:
- a remailer-to-newsgroup anonymous poster, which lets you
	send the remailer articles (presumably with unlabelled keys)
	to be posted to the alt.whatever group -- should be an easy combination
	of existing tools.
- include an optional non-address label along with the unlabelled message.
	If you're having an ongoing secret conversation with somebody,
	you can secretly tell them the label to include, 
		Subject: Unlabelled PGP message label: fnord
	If you don't see the fnords, you don't have to decrypt them.

	You don't want to use anything that can be traced to you,
	and you probably don't want to use labels in a sequence,
	or use the same label throughout a conversation, but it could help.

	You could also, if you're only mildly paranoid, use something
	like a 4-bit checksum of the PGP key or the key length as a label 
	- it's not enough to identify which key it is, but it's enough
	to cut down on your decryption by a factor of 16.
	A longer checksum is too revealing - even 8 bits identifies 
	1/256th of the crypto community, which isn't very anonymous.

	With all these methods, if you're concerned about traffic analysis,
	you've still got to download the messages you don't care about
	to your machine before discarding them.

- The Conventional Data Encryption (DEK) packet includes a checksum,
	which lets you know if you've successfully decrypted it
	using the RSA key, so you can tell quickly enough whether a message
	is for you, without decrypting the message itself.
	The RSA step probably takes most of the time for short messages,
	but it's still a win.

	(PGP does lose some security this way, since the Bad Guys can also tell
	if their exhaustive search of PGP keys has gotten the right one,
	and now they can go beat up the Key-Certifier to find out
	who the key really belongs to, but it's a start.
	If you want heavier anonymity, you have to do without the checksum.
	There's also an extremely small chance of an incorrect PGP key
	producing a correct checksum, but it's about 2**-26, and 
	it still gives an incorrect session key.)

				Bill Stewart, somewhere in New Jersey



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Mon, 30 Nov 92 19:50:44 PST
To: cypherpunks@toad.com
Subject: Re: remailers
Message-ID: <9212010311.AA24273@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Fen Labalme quotes some messages with concerns about people needing
permission from the sysadmins to run remailers.

The current remailers, based on Eric Hughes' approach, don't have this
problem.  I don't even know who the sysadmin is on the system where I
run the remailer.  They don't know anything about it.  Eric's
remailers don't require continual processes to be run, root
privileges, hacking the mail tables, or anything special.

All you need is to be on a Unix system which supports the ".forward"
file.  This is typically implemented by the mail programs which
deliver mail to the user's mail file.  The programs check to see if a
file called .forward exists in the user's home directory, and if so
they treat its contents as either a program to pipe the incoming mail
into, or a user name or list of user names to send the mail to.

This is the hook by which Eric's remailers operate.  The .forward file
is set up so that mail is piped to a program which sorts the mail
based on its headers, using the mh utility slocal or, in my case, a
perl script which provides some of the same functions.  Each message
is checked like this, and if it doesn't contain any of the special
stuff which activates the remailer software, it is simply deposted in
the user's mailbox file as usual.  Otherwise the remailers run and
forward it as requested.

With this solution, there's no need for anybody to be aware that you
are running a remailer, as long as it's not too much of a load in
terms of extra message traffic.

Hal
74076.1041@compuserve.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: S.E. Brown <shawnb@ecst.csuchico.edu>
Date: Mon, 30 Nov 92 20:18:21 PST
To: cypherpunks@toad.com
Subject: 386des wanted
Message-ID: <9212010418.AA02687@toad.com>
MIME-Version: 1.0
Content-Type: text/plain



Does anyone possess a copy of the des package 386des? I've heard that it
is incredibly fast, and would like to look at a copy. I have been unable
to find it on any of the regular crypto haunts on the inet.

Thanks in advance

Shawn




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Mon, 30 Nov 92 17:41:25 PST
To: wcs@anchor.ho.att.com  (Bill Stewart)
Subject: Re: Unlabelled PGP messages
In-Reply-To: <9211302245.AA04980@anchor.ho.att.com>
Message-ID: <9212010141.AA18205@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


[talks about posting anonymous messages that only recipient can decrypt]

> 	like a 4-bit checksum of the PGP key or the key length as a label 
> 	- it's not enough to identify which key it is, but it's enough
> 	to cut down on your decryption by a factor of 16.
> 	A longer checksum is too revealing - even 8 bits identifies 
> 	1/256th of the crypto community, which isn't very anonymous.

Why not generate a key just for this conversation, and then post a full
128-bit (22 base64 characters) hash in the subject.

You can even have a key for each message if the conconversation is two-way
then whenever you are about to send a message you can generate a new key
pair and include the new public key with your message.  

As soon as you receive and decrypt the message for that key, destroy the
private key.  






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 30 Nov 92 18:39:37 PST
To: hughes@soda.berkeley.edu
Subject: thoughts on digital cash
In-Reply-To: <9211302241.AA00770@soda.berkeley.edu>
Message-ID: <9212010219.AA19516@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: Eric Hughes <hughes@soda.berkeley.edu>

>>However, I'm so certain that the law in the U.S. requires
>>that the bank have full information on the holders of all accounts
>>that I'm willing to bet $150 right now with anyone who believes
>>otherwise. 

>You've certainly showed us that you believe this Perry, but otherwise
>this statement contains no educational content.  This, to me, sounds
>like a grown-up version of "Is so!!!" backed up by "My bank account
>can beat up your bank account!"

I'm sorry, but I can't be troubled to spend time looking for the
regulation otherwise. This is tantamount to asking me to bother
spending time looking up where in the law books precisely running red
lights is outlawed. I'm certain its illegal, but have very little
interest without a monetary incentive to go and look up precisely
where it says so -- I'd gain no interesting information personally.
I'd have to take time off of work and go to a law library to determine
precisely where in the mass of regulations and laws this particular
practice is prohibited. For $150, the hour or so of my time involved,
although not well compensated for, would at least be sufficiently
compensated for that I would bother.  Obviously, this is not evidence
of the truth, but as you have noted, it is evidence of a very strong
belief. If you have evidence to the contrary, here is your chance not
only to make $150 but to have me do all the work required for you to
get your $150.

>You made a claim of fact.  I'm asking for you to provide a reference
>in support of your claim.  Simple rational discourse.

You don't have to believe me if you don't want to.  As I've said, I
have very little incentive to track down the specific place that the
practice of permitting anonymous accounts is outlawed -- but I'm as
certain of it as I am that driving a car requires a license in all 50
states. If I asserted that fact, and you desired evidence, I would
have a similar lack of desire to go and look up where specifically in
the law books of all the states that driving without a license was
listed as a violation. Doing legal research of this kind is not
entirely unpleasant, but it is tedious and would put me out of my way,
little or no reward.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Joe Thomas <jthomas@access.digex.com>
Date: Mon, 30 Nov 92 18:46:33 PST
To: cypherpunks@toad.com
Subject: Rumors of your existence
Message-ID: <Pine.3.05.9211302147.A25358-9100000@access.digex.com>
MIME-Version: 1.0
Content-Type: text/plain


As a follower of sci.crypt and comp.org.eff.talk, I felt I had to check up
on the owners, if any, of this e-mail mailbox that was listed at the end
of St. Jude's "Cypherpunk Movement" article in Mondo 2000 Issue 8.
How "patently false" are the rumors you can be contacted here?

Joe






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Mon, 30 Nov 92 22:48:00 PST
To: cypherpunks@toad.com
Subject: John Gilmore on CNN
Message-ID: <9212010643.AA01350@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Our own John Gilmore's fame in the NSA-tweaking community continues.

I just saw John interviewed by CNN for a report on crypto, the recent
case involving the Friedman papers, and RSA Data Security's
problems getting export licenses for its products. The piece ran on
"Headline News," and possibly on the main CNN channel as well (as is typical).

John spoke about crypto and the need for private individuals to have
secure communications, a woman from CPSR spoke about recent threats to
further limits communications privacy, and Jim Bidzos from RSA spoke
about licensing for exports. The NSA had no substantive comment.

All in all, no surprises for any of us. It was too brief, of course,
but seemed fairly done. Reports like this will gradually get the word out.

By the way, you should all check out John's excellent articles he
wrote in sci.crypt about the declassification of the Friedman papers.
If you don't have Usenet access, I'll mail them to the first several
people who request them. (I'd just post them here, but John's in Japan and
I can't get his permission.)

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Tue, 1 Dec 92 00:40:47 PST
To: uunet!shearson.com!pmetzger@uunet.UU.NET
Subject: thoughts on digital cash
In-Reply-To: <9212010219.AA19516@newsu.shearson.com>
Message-ID: <9212010700.AA24193@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


For important claims like that, the value added is that other people
putting in voluntary effort to produce things spend it in places that
better satisfy your desires.  It certainly is an indirect reward,
however.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc Horowitz <marc@Athena.MIT.EDU>
Date: Mon, 30 Nov 92 21:13:48 PST
To: cypherpunks@toad.com
Subject: Chaum's DigiCash
Message-ID: <9212010513.AA05283@steve-dallas.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


Does anybody have any contact information for David Chaum or DigiCash?
I think it's worthwhile to find out if any of the problems we've been
discussing have been previously solved.  It's possible that our
experiment could increase visibility of digital cash to the point that
a real commercial venture could work, in which case he may even be
interested in helping us.

Email me personally, I'll summarize.

		Marc




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Tue, 1 Dec 92 02:24:57 PST
To: phr@napa.Telebit.COM
Subject: Re:  Secure Key exchange
Message-ID: <9212011022.AA25238@servo>
MIME-Version: 1.0
Content-Type: text/plain


<phr@napa.Telebit.COM> allegedly asks:
>> If you meet someone claiming to be John Gilmore,
>> how will you know he's not an impostor?

Get a copy of last Saturday's New York Times. John's picture appears
on page 7. Of course, it's always possible for the NSA to print up a
"special edition" of that paper just for you... :-)

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Tue, 1 Dec 92 02:28:08 PST
To: pmetzger@shearson.com
Subject: Re:  Secure key exchange
Message-ID: <9212011027.AA25256@servo>
MIME-Version: 1.0
Content-Type: text/plain


>Just to point out, though, this is not foolproof. A good impressionist
>can fool people, especially if they are extremely skilled.

Perhaps. But if it's someone you know well, the imposter may have a
hard time passing that particular Turing Test. For example, Jeff
Schiller called me the other night, nominally to compare our RSA
public keys before signing, but we ended up chewing the fat for nearly
an hour.  It would be hard for an imposter to duplicate that feat
without arousing my suspicion.

Another (somewhat more likely) possibility is that the NSA or FBI
might be holding a gun to the guy's head when you call him up to
verify the key you got with his name on it. Perhaps we need "duress"
hash codes. :-)

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mlf3@Lehigh.EDU (Matt Fante)
Date: Tue, 1 Dec 92 07:03:51 PST
To: cypherpunks@toad.com
Subject: Nonlinear CODEC of the digital domain
Message-ID: <199212011455.AA69037@ns3.CC.Lehigh.EDU>
MIME-Version: 1.0
Content-Type: text/plain


Here is a new crypto idea - I would appreciate some feedback!

Matt.

My senior project is the extension of a grad student's *published*
thesis entitled "Nonlinear CODEC in the digital domain".

I use essentially a digitial filter to encode/decode the digital domain.
I believe that it has applications to data security and I welcome
people's input to this claim.


The encoder.  My prototype encodes 4-bits but I have software that
works for n bits.  If you would like to have the software let me know.
I'm not an ASCII artist but here goes my best block diagram of the
IIR digital filter encoder:


           x[n] ---------> + --------------------------> u[n]
                           ^                    |
                           |                    |
                           |                    |
                           |                    |
                           |              --------------
                           |              |   z^(-1)   |
                           |              --------------
                           |                    |
                           |                    |
                           |                    |
                           + <------------------|
                           ^                    |
                           |              ---------------
                           |              |   z^(-1)    |
                           |              ---------------
                           |                    |
                           |                    |
                           |              ---------------
                           |              | Left Circ   |
                           |              ---------------
                           |                    |
                           |                    |
                           ----------------------

x[n] is the input data word, u[n] is the encoded output word,
z^(-1) (z transform) is a delay element and Left_Circ is the left
circulate function, i.e. Left_Circ(10)=5 (10 has binary representation
1010 and upon left circulation we get 0101 which has decimal representation
5).  Another example is Left_Circ(3)=6.

Clearly this filter is IIR with function:

 u[n] = x[n] + u[n-1] + Left_Circ( u[n-2] )

the decode is FIR and is found by solving for x[n]

 x[n] = u[n] - u[n-1] - Left_Circ( u[n-2] )

I won't bother you with another ASCII block diagram.

I have run all kinds of signals (in software) through the filter
pair.  I get, what seems to me, a moderately secure coding of the
digital domain with exact signal reconstruction from its coded form.

Both Wavelet and Fourier techniques have failed to find anything
"interesting" in the encoded domain.


Please play around with this and send me feedback ( mlf3@Lehigh.EDU )

Matt.
________________________________________________________________
                         Matt Fante
________________________________________________________________




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Mon, 30 Nov 92 15:27:53 PST
To: cypherpunks@toad.com
Subject: Offshore banking..
Message-ID: <9211302309.AA12369@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain



With respect to offshore banking, what about the legislation governing the
export of money from the coutry? Here in Australia if we send an amount of
money overseas then we have to pay a tax/levy of an amount based on the
size of the funds being sent offshore.

If we start snailmailing certified envelopes full of money overseas then
someone will want to know about it so they can tax us. 

Im fairly sure there wouldnt be a problem (from the governemnt) with 
shuffling your funds from offshore bank to offshore bank. If encrypted
money was going in and out all the time from a (legal) onshore bank that
accepted digital transactions to an offshore one, then you would face the
same export laws.

How do the banks handle this when they send fifteen trillion overseas to
have their money working for them while we all sleep at night....?

Mark
mark@coombs.anu.edu.au




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Tue, 1 Dec 92 09:03:17 PST
To: cypherpunks@toad.com
Subject: remailer scripts
Message-ID: <9212011702.AA01281@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



In a previous message, Hal Finney describes in general terms how the
anonymous remailer works.

I have a "spare" account I could use to set up such scripts - it's an
HP9000 model 730 running HP-UX (if that matters).

So if someone will send me the scripts, I will try to install them and
test them myself.  And if I get it working, there will be a new anonymous
remailer for our use...

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Tue, 1 Dec 92 09:18:49 PST
To: cypherpunks@toad.com
Subject: Nike says: Just Do It
Message-ID: <9212011718.AA01351@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



I agree with Mark's letter: we've philosophized enough - let's
implement a digital bank.

The only thing I have to go on is a recently posted summary of a
digital cash scenario - apologizes to the poster, I don't have the
article handy and I can't remember who nicely summarized the protocol.
If that summary isn't good enough, I'll go look for more of Chaum's
stuff.

I'm willing to help pull such a feat off - even if to start I (and
anybody else who wants to help!) take Email and respond by hand.  

The only high precision math routines I have are the rsa programs that
are available @ghost.unimi.dsi.it (see Dave Vincenzetti's (sp?) recent
message on sci.crypt) OR what I used during my crypto class for
working through various protocols: Mathematica.  Automating the
procedure can come later, and I'm willing to work with anybody in
doing that as well.  If initially the transactions are handled by hand
and Mathematica, don't expect a rapid turnaround! :-) The nice thing
about Mathematica is that I can run it remotely and don't need to be
in front of the NeXT to do it - especially since the command line
version is good enough for out purposes: high precision integer math,
etc.

I remember the protocol involved a hash (MD5 is suggested) of an input
to produce a number.  Suggestions?  Would turning the MD5 output into
a hex number be good enough?

Anyway, I'm going to work through the protocol a few times by hand and
post again with more info in a bit...

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: The Phantom <phantom@u.washington.edu>
Date: Tue, 1 Dec 92 13:32:27 PST
To: cypherpunks@toad.com
Subject: PGP and Digi-money
Message-ID: <Pine.3.05.9212011301.B25355-b100000@stein.u.washington.edu>
MIME-Version: 1.0
Content-Type: text/plain


	Well, it looks like it is going to happen. I, too, am interested
in seeing the experiment run. The way it was talked about earlier this
week, I pictured a system where people would snail-mail an amount of money
to a central authority (bank) and would be turned into credits. Since this
was only a simulation (not to raise eyebrows) I was thinking that a cap
could be established (say, $25). Now it looks as if we'll have no acutal
cash backing for the first simulation. How will this be distributed?
Should everyone on the list be given a set amount of digital cash to start
the 'poker game', or will we choose a smaller, representative sample? 
	For the game, we'll have to set up an account as an internet
`bank', scripts to handle incoming cash requests, etc. Are these the least
of our worries? 

	I'm also willing to help in any way I can, although I too know
little C. I have a decent background in various other areas which may be
helpful. 

	On an entirely different subject: Has anyone worked up a PGP
version that may help me out? My 286 plugs along when working on keys. :)
I am specifically wondering if anyone has hacked in and created a PGP that
supports the '87 coprocessor.

thanks-


Matt Thomlinson
University of Washington, Seattle, Washington.
Internet: phantom@u.washington.edu      	    phone: (206) 528-5732
PGP 2.0 key availaible via email or finger phantom@hardy.u.washington.edu






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Tue, 1 Dec 92 10:17:44 PST
To: extropians@gnu.ai.mit.edu
Subject: Lazy man's PGP key collection
Message-ID: <9212011758.AA05964@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


I collect PGP keys with a PGP keys mailbox.
Instead of trashing a message when I'm through reading it, if it has
a PGP key, I transfer it to the PGP keys mailbox.  In Eudora that means
pulling down the Transfer menu to the "-> PGP keys" entry.

These are, of course, only play keys.  They could be from people who aren't
who they say they are, or they could have been tampered with on the way to
me.  Unless they've been signed by someone I trust and have a trustworthy
key for.  (Just a standard disclaimer anytime I mention public keys.)

-fnerd
only her cryptographer knows for sure
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Tue, 1 Dec 92 10:17:33 PST
To: cypherpunks@toad.com
Subject: Re: How far is to far?
Message-ID: <9212011758.AB05964@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


Mark (mark@coombs.anu.edu.au) sed

> Maybe it's not in the spirit of this mailing group but 

Seems on topic to me.

> what of the question
> of purposeful abuse of the anon mailers/newsposters? Say for instance some
> person posts either a sh*tload of garbage to every known group, flooding
> the USENET...

Tim May and Fen Labalme have given good replies.

I hate the sloppy setup of the internet/usenet/netnews/mailing-lists
in general.  The way things are gives anarchy a bad name, and I think 
they could use a good hosing off--if only that would mean they would
get cleaned.  Unfortunately the way people react to abuses is often 
just to add extra patches.

Take "kill files," which Tim mentions.  The thing I hate about that term
(even more than that they're lists of people to "kill,") is that they're
after-the-fact.  Here's this mail that keeps pouring into my mailbox, and
every day my robot has to find and burn the 90% that even a robot can be
taught to recognize as junk.  Prompt, temporary STUPID relief of symptoms.

(I mean, while I'm at it, I hate the broadcast-and-filter model of netnews,
CD ROMs, and cable TV.  I want things available for me to go fetch.)

That kind of filtering has a place, but I like more positive-reputation,
positive-interest models.  Like subscription mail groups.  Also, I
understand that Fido users have to pay their own transport charges.  I
don't know if that applies to the "echo" groups, but it should...Mr. 
Jennings?...because that's another natural kind of filtering against
network hosing.  You can flood my mailbox if you pay me enough.

>> or a more personal attack whereby they send out anonymously 
>> information that was so fundamentally personal to someone they could
>> possibly react very badly....
>> 
>> What if someone posted some top secret information and the various three
>> letter acronyms all went out for someone's blood.

I guess these won't happen much, just judging from how much they happen now
even though they're not that hard to do.  But sure, they'll happen.

It would be nice if people learned information-hygene lessons like
skepticism and protecting privacy, and accepting-life lessons like accepting
what does get revealed about oneself and others...(whistful grin).

More like, people will learn if we teach; things will change if we change
them.  Scary issues are good educational material when used right, 
especially when you can say, "This is stupid and it can be *fixed* and
we can use your help."

-fnerd
quote me...within *reason* of course
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Mon, 30 Nov 92 19:38:20 PST
To: cypherpunks@toad.com
Subject: Why not just do it?
Message-ID: <9212010337.AA21322@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain



With all the talk of banking regulations etc with regard to messing
with the monetary system, why dont we just create a test system where
everyone emails in an amount that they are prepared to coughup if 
they really had to, but at the moment dont (have to).

Then we can go ahead with the digital "cash" scenario and not be
governed by the banking/security laws of any country because no real
money is involved. 

The object is to get a system going, find flaws, create software and 
protocols and basically experiment with it. The issue of actual cold 
hard cash is, to me, a not important. After all it's just numbers.

Eric volunteered to do this earlier and, if he still wishes to, I'd be
willing to participate in it. Maybe he doesnt have the benefit of a big
cushy bank trust account earning him intrest for his work, but I dont
think that was a consideration for him anyway.

Mark
mark@coombs.anu.edu.au




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Tue, 1 Dec 92 14:40:32 PST
To: cypherpunks@toad.com
Subject: Re:  PGP and Digi-money
Message-ID: <9212012239.AA25238@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



"Should everyone on the list be given a set amount of digital cash to start
 the 'poker game', or will we choose a smaller, representative sample? "

Maybe we should generate some digicash with a PostScript printer, just to
make it interesting.

I wonder how public key cryptology would effect efforts to counterfeit ?
It seems to me that this same technology could make cash much harder to
forge ... even allowing one to actually _print_ one's tender, authenticated
by the information buried in the serial number of the bill ... and it would
be the serial numbers that the bank would track, not the actual pieces of
paper.

-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

                    Klein flask for rent. Inquire within.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: The Phantom <phantom@u.washington.edu>
Date: Tue, 1 Dec 92 15:00:53 PST
To: cypherpunks@toad.com
Subject: whoops! Too much 8086 assembly,
Message-ID: <Pine.3.05.9212011428.B9038-9100000@stein.u.washington.edu>
MIME-Version: 1.0
Content-Type: text/plain


Too much assembly language and not enough FPU support. It was pointed out
that I should simply try recompiling with the coprocessor option. :l
Sure easier than writing it in assembly, eh?

ahem. 

thanks for you time -

Matt Thomlinson
University of Washington, Seattle, Washington.
Internet: phantom@u.washington.edu      	    phone: (206) 528-5732
PGP 2.0 key availaible via email or finger phantom@hardy.u.washington.edu





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Tue, 1 Dec 92 19:20:22 PST
To: cypherpunks@toad.com
Subject: anonymous remailer
Message-ID: <9212020319.AA03423@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



Fellow cypherpunks:

There is a new anonymous remailer for our use.  Its address is
elee7h5@rosebud.ee.uh.edu, its name is "remailer03", and here is the
public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm
uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v
gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR
tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1Pg==
=9mBX
-----END PGP PUBLIC KEY BLOCK-----


Also, here is a script I have to use the remailers.  It is the
ultimate in brute force :-)  Perhaps if more people implemented
remailers, a general script can be written to bounce mail off them
all, or a subset of them all, in the style of Bill's scripts which were
recently posted.  It didn't take long at all to set up: I spent most
the time installing perl in my account, and tracing down an annoying
bug that was my fault - I forgot to make the *.pl files executable.  

-----------8<--------->8----------
if [ $# != 3 ]
then
	echo "Usage: anon.mail message destination remailer"
	exit 1
fi

anon1=remailing
mail1=hal@alumni.caltech.edu
anon2=remailer
mail2=remailer@rebma.mn.org
anon3=remailer03
mail3=elee7h5@rosebud.ee.uh.edu

message=$1
dest=$2

if [ $3 = remailing -o $3 = hal -o $3 = alumni -o $3 = 1 ]
then
  remail=$anon1
  mailaddr=$mail1
fi

if [ $3 = remailer -o $3 = rebma -o $3 = 2 ]
then
  remail=$anon2
  mailaddr=$mail2
fi

if [ $3 = remailer03 -o $3 = elee7h5 -o $3 = rosebud -o $3 = 3 ]
then
  remail=$anon3
  mailaddr=$mail3
fi

t1=.anon1
t2=.anon2

echo "::" > $t1
echo "Request-Remailing-To: $dest" >> $t1
echo "" >> $t1
pgp -ea $t1 $remail

echo "::" > $t2
echo "Encrypted: PGP" >> $t2
echo "" >> $t2
cat $t1.asc >> $t2
cat $message >> $t2

rm -rf $t1 $t1.asc
mail $mailaddr < $t2
-----------8<--------->8----------




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill O'Hanlon <wmo@rebma.rebma.mn.org>
Date: Tue, 1 Dec 92 20:27:29 PST
To: cypherpunks@toad.com
Subject: Re: anonymous remailer
In-Reply-To: <9212020319.AA03423@tree.egr.uh.edu>
Message-ID: <m0mwlGE-0006U1C@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


>
>
>Fellow cypherpunks:
>

(Karl's remailer announcement, key, and script elided.  Thanks, Karl -- the
more the merrier!  And the more, the safer, I would think.)

I've got a couple really trivial comments.  Karl, your script called "mail"
to deliver the file.  Looks like it works on your machine, but on mine,
"mail" called /bin/mail, which seemed to put an "Apparently-To: xxx" header
in the message, and messed things up.  If any of you have a problem with
Karl's script, you might check that.  I used elm to send the file, but I
would think /bin/mailx or /bin/Mail (depending on what Unix you're using)
would work as well.

Also, I'm hoping one of you who is proficient in perl will rewrite the
darn thing.  It needs generalizing, and perl's just the language for
the job...  As a Bourne shell script, it looks ugly, especially with all
those temporary files all over the place.

-Bill
-- 
Bill O'Hanlon						 wmo@rebma.mn.org



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hugh@domingo.teracons.com (Hugh Daniel)
Date: Wed, 2 Dec 92 04:49:15 PST
To: cypherpunks@toad.com
Subject: Help with the contents of the Cypherpunks Mail Archive
Message-ID: <9212021248.AA08444@domingo.teracons.com>
MIME-Version: 1.0
Content-Type: text/plain


  As I said I would at the last 'in person' meeting I am starting up a
mail archive of usefull things for old and new Cypherpunks.  At first
we will have a few files that can requested over email, ftp and more
complex files sturctures might come later.

  The most important files that needs to get built are the FAQ
(Frequently Asked Questions), the Glossary and the bibliographys.
These need to be done keeping in mind who we want to reach, the
programmer new to crypto systems and useage.
  This is a group effort, if you have a good definition of a word send
it to me, I will likely use it!  If you think you can do a great job
of describeing one of the questions from the FAQ in a page or so,
whip it out and send it to me!  I will compile/edit what ever comes my
way into the right place in the archive files.

  Once we have a good FAQ then when new folks join the list we can
send them the FAQ to read and get them up to speed that much faster.
This will mean that we will have just repetition on the main list and
therefore a better signal to noise ratio!

  So, go over the list at the end of this email message and see if
there is anything you want to tackle, and if there is write some of
that English code!

		||ugh Daniel
		Keeper of the archive for now...

Propsed contents of the Cypherpunks mail archive.

Glossory

Bibliography

Beginers Anotated Bibliography by Subject

FAQ --- A beginers guide to Cypherpunking
	What is the cypherpunks list all about?
	Why do I need crypto?
	What is privacy?
	What are public keys?
	What is the differences between DES & RSA?
	Why can't I just use rot13?
	Why is generateing random numbers hard?
	Why do crypto in software insted of hardware?
	Why is this crypto stuff still legal?
	What journals are there on this subject?
	What are the good beginer books on crypto systems?
	What is the NSA and why does everyone seem to hate them?
	What is crypto anarchy?
	Is all I need to crypt my email?
	What are remailers and DC-Nets?
	What can I do?


Sources
	Remailer sources
	Random number generators & testers




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Wed, 2 Dec 92 06:34:45 PST
To: cypherpunks@toad.com
Subject: summary of remailers
Message-ID: <9212021434.AA04655@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



Here is a summary of the currently available anonymous remailers:

hal@alumni.caltech.edu

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.01

mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi
T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2
aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg==
=K00H
-----END PGP PUBLIC KEY BLOCK-----


remailer@rebma.mn.org

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD
WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b
yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR
tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKQ==
=/qHx
-----END PGP PUBLIC KEY BLOCK-----


elee7h5@rosebud.ee.uh.edu

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm
uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v
gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR
tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1Pg==
=9mBX
-----END PGP PUBLIC KEY BLOCK-----


/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Wed, 2 Dec 92 13:16:58 PST
To: uunet!toad.com!hugh@uunet.UU.NET
Subject: Help with the contents of the Cypherpunks Mail Archive
In-Reply-To: <9212021248.AA08444@domingo.teracons.com>
Message-ID: <9212021905.AA04514@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


Other topics for the FAQ:

crypto for authentication
pseudonyms
economics of privacy/security
what's in a reputation
digital cash
verifying keys

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@rosebud.ee.uh.edu
Date: Wed, 2 Dec 92 09:12:11 PST
To: cypherpunks@toad.com
Subject: .
Message-ID: <9212021712.AA14781@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Subject: Digital Cash

One point of digital cash is to allow electronic payments, so printing
it on paper would not be useful as other than a novelty.  People would
have to scan the bit patterns back in, which would be inconvenient.

How big will a piece of digital cash be?

An electronic "dollar bill" in the simple scheme of Chaum's consists
of two parts:  (x, f(x)^(1/e).  X is a random number, f(x) is a one-way
function like MD5, and e is the exponent which could be taken to represent
the denomination of the bill.  MD5 takes 64 bytes as an input "chunk"
so that would be a natural size for x.  f(x)^(1/e) is f(x) "signed" by
the bank using exponent e, so that would be about the size of the bank's
modulus n, say 1024 bits or 128 bytes.  Probably there would be some
control information as well.  So the total size of an electronic banknote
would be 128 + 64 + a few, or about 200 bytes, maybe a little more.
To print this you'd have to Ascii-encode it, which generally expands
things by 1/3, so you'd get about 270 to 300 characters per bill/coin.
This would be around four or five lines of text, comparable to a PGP
key (and looking about as interesting - totally jumbled letters and
numbers).

"Forgery" is in one sense hard and in one sense easy.  It's hard because
to create new dollar bills because you have to forge a signature using
the bank's public key (n, e).  This is equivalent to breaking at least
some uses of RSA.

But it's easy to reproduce existing electronic dollars, and you don't even
need a Xerox machine.  Just "copy dollar1 dollar2" on your PC, and repeat
the process.  Presto, plenty of dollars, all exactly the same.  Send one
to the butcher, one to the baker, and you've still got plenty more
where those came from.

Keeping this kind of re-use from occurring is one of the things that
makes electronic cash tricky.  Chaum's simple scheme has the receiver
of cash calling the bank or sending the cash there right away.  The
bank has a list of "serial numbers" for all the cash that's ever been
deposited, which it compares against to see if this is a re-use.  The
first person to deposit a dollar with a given serial number gets credit
for it; the others are told that it's worthless.

Another area that people seem a little unclear about is the difference
between electronic cash and electronic checking accounts.  A checking
account could be managed by simple RSA-signed messages (e.g. created with
PGP) saying, please transfer $X.00 to account number XYZ.  If you wanted
to buy something from someone, you'd find out what his account number
is with the bank, write up a little note like this, sign it using your
public key with PGP, and email it to the person that you wanted to buy
from.  He'd send it on to the bank and his account would get credited.
Again, you'd want to put a serial number on your check so that the guy
couldn't send it again tomorrow and get another $X.00.

Or, you could just send it directly to the bank and request the bank to
notify the seller that the funds had been transferred.  This would seem
to avoid the re-use problem.

The difference between this system and electronic cash is that the bank
knows exactly what is going on.  It sees all transactions, so it knows
which accounts are making payments to which other accounts.  This is
true of ordinary paper checking accounts as well, of course.

Electronic cash is designed so that not even the bank can tell who is
paying whom.  I withdraw some cash, say, $100.00, and I pay you $35.00
by mailing you the electronic bills.  You deposit them.  The bank has
no way of determining which particular withdrawal produced those bills
which you are depositing.  This is, more or less, how real cash works.

Hal
74076.1041@compuserve.com






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 2 Dec 92 12:32:11 PST
To: cypherpunks@toad.com
Subject: FAQ in sci.crypt
Message-ID: <9212022031.AA14301@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks of Cypherspace,

I just found a new FAQ and bibliography in sci.crypt. It's by Larry
Loen and is intended as a stopgap FAQ, as sci.crypt hasn't had a good
FAQ in a while. It doesn't cover the digital cash, anonymous
remailers, crypto anarchy, etc. kinds of stuff, but it answers FAQs
about one-time pads, ciphers, RSA, etc.

Since this is a mailing list, I will not forward it. (It's 26 or so
screenfuls of VT-100 screens, which is fairly long.)

Also, I still have the "Crypto Glossary" available for forwarding to
any newcomers to this list.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Wed, 2 Dec 92 13:22:39 PST
To: cypherpunks@toad.com
Subject: Suggest splitting things up
Message-ID: <9212022122.AA16492@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


To Cypherpunks:

Greetings,  Back on-line again,  after wading through about 225 messages
that has accumulated in the last 4 days.   The volume of messages
is really getting high,  and perhaps we might want to try and break
them up into the following proposed lists.

  a) PGP Development - a mailing list has already been set up,  but
     is reserved exclusivly for those doing the actual coding work.
     
  b) Digital money - A lot of traffic seems to contain this subject,
     which is all very interesting,  but doesn't apply to me because
     money is something I never seem to have anyway.
     
  c) Key management and collaboration - for discussion on various key
     exchange methodology.
     
Anyway,  this is just a thought.    And might help to cut down traffic.
One also might consider setting up a newsgroup.

JD




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Thu, 3 Dec 92 15:26:58 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Re: Secure key exchange
Message-ID: <ecF7uB10w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


Anserwing some comments about my suggestions for key verification.
 
Phil Karn pointed out that the next version of PGP will display an
MD-5 hash of any public key for phone comparison purposes.  That's
great, but that version of PGP isn't here quite yet. I suspect, in
any case, that the added security isn't all that great since I suspect
it's very hard to find another valid key-pair where the public key
matches the last 24 bits plus some fragment of another 20 bits or so
from the middle of the key.
 
Phone, as opposed to mailed paper verifications has the following
problems:
 
Phil says you have to recognize the voice, which implies you've met
him in close quarters, which implies you could have exchanged keys
physically anyway.  If the only place you've heard the voice is
over the phone, that's not a very good criterion.
 
Phone verification is good, IMHO, *only* if the person being verified
is *called at a listed number*. You can't verify a person who calls you,
(unless you know the voice).  You can't verify a person you call at
an unlisted number which you got over the net!!
 
Economics: Net participants are scattered over the country and even the
world. Paper verification costs about $2-$3 allowing for my fee, copying
costs and two-way international postage. Adding notarization adds about
$5.00.  Phone verification is economical locally (maybe cheaper than
mail), but more expensive when long-distance rates apply, especially
international rates.
 
Meeting at parties or face-to-face is most expensive of all, unless
the meeting happens fortuitously. Overseas plane fare to exchange keys
is beyond the means of most of us.
 
Phil says:
 
    I would much rather trust a simple verification procedure based on
    redundancy and close personal relationships than a single,
    complex, impersonal process involving people I don't know.  This
    is not to impugn your integrity, of course -- I'm simply speaking
    on principle.
 
No offense taken!  I, on the other hand, would rather have in my hand
a signed statement of identity with photocopied ID that I can keep
and file away.  I also don't want to go broke making international
phone calls.
 
As it happens, I, so far, have not been able to sign a single key!!
 
I called Phil Zimmerman at a listed number, I read him my key and
he signed it, but he was called away from the phone before he could
verify his key to me. So I can't sign his!
 
I've met a few people at parties I've given my paper key (fragments)
to. So far none of them have signed my key, but none of them had
paper key fragments to trade, so I can't sign theirs.
 
George Gleason commented about supplying home addresses.  Your
comments are well taken. Phil Zimmerman also commented to me in E-mail
that some people don't want the serial numbers on their photo ID
copied.  Everyone please feel free not to supply a home address and
to obscure any home address or serial number on the photocopied
photo ID. I'll still sign your key, although I'll note what you did
in my signed key directory, which I'll send to customers & publish
here.  If you don't want *me* to know your home address, you can
use a P.O. box for me to return my (or other customers') ID
certificate(s) to you. On the other hand, as the service provider,
MY home address and phone are public info.
 
I also acknowledge George's criticism re the "I'm not a cop"
statement. I'm going to leave it in my statement, because it's
true, but in general you should be aware that any legal protection is
questionable at best.  The lack of protection has been verified by
a source on Extropians and by an attorney on the RIME network.
 
In the meantime, I guess we can discuss illegal subjects not with
"I've done ..." but with "I've heard that ..." or "I used to know
somebody who ...". Also anonymous remailers will be a big help.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: centaur@netcom.com (Paul Blair)
Date: Wed, 2 Dec 92 14:53:33 PST
To: cypherpunks@toad.com
Subject: Information wanted
Message-ID: <9212022252.AA07012@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain




	Hello there!  I'm interested in getting information on the
cypherpunk movement.  Could y'all perhaps e-mail me back with your
manifesto and suchlike things?  Much obliged!

     Paul
-- 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: John W Noerenberg <jwn2@qualcomm.com>
Date: Wed, 2 Dec 92 16:01:19 PST
To: crunch@netcom.com (John Draper)
Subject: Re: Suggest splitting things up
Message-ID: <9212030000.AA02120@harvey>
MIME-Version: 1.0
Content-Type: text/plain


At  1:22 PM 12/2/92 -0800, John Draper wrote:

>To Cypherpunks:
>
>Greetings,  Back on-line again,  after wading through about 225 messages
>that has accumulated in the last 4 days.   The volume of messages
>is really getting high,  and perhaps we might want to try and break
>them up into the following proposed lists.

Sounds like a fine idea.

john noerenberg
jwn2@qualcomm.com
noerenberg.j (Applelink)
===========================================================
Do not uselessly lament your luck that is giving way, your work that has
failed, your life's plans that have all ended in despair.  Like a man long
prepared, like a man of courage, bid her farewell, the Alexandria that
leaves you.
-- "The God Abandons Anthony", Constantine Peter Cavafy [1911]
===========================================================





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@rosebud.ee.uh.edu
Date: Wed, 2 Dec 92 16:43:39 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9212030043.AA01011@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


This is a test post of a triple-remailed message, all encrypted.
Sent at Wed Dec  2 16:17:47 GMT 1992

(Signed)
Guess Who?







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Wed, 2 Dec 92 18:17:58 PST
To: cypherpunks@toad.com
Subject: digital banking, file formats, etc.
Message-ID: <9212030217.AA07111@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



This is a run through of Hal Finney's summary of the bank protocol.
Here is what I envision the digital bank working like, with rough  
sketches of file formats, conspicuously similar to the remailer's  
:-):

1) Alice chooses x, r
   Alice computes B = r^3 * f(x) mod n
   Alice sends the following message to the bank via an anonymous  
remailer

    ::
    withdraw
    <account name>
    <B = r^3 * f(x) mod n>
    Reply-To: <an anonymous remailer>
    <remailing request to Alice encrypted with appropriate remailer  
public key>

In the final version, this message will be encrypted as well

2) Bank computes D = B^(1/3)
   checks <account name> for balance, withdraws if ok
   Bank sends to appropriate remailer

    ::
    Encrypted: PGP

    <remailing request included in Alice's mail>

    <D>

3) Alice computes C = f(x)^(1/3) by dividing D by r.
   Alice gives Bob (x, C) - via anonymous mail, presumably :-)

4) Bob wants to verify (x, C)
   Bob mails to Bank via anonymous remailer

    ::
    verify
    <x>
    <C>
    Reply-To: <an anonymous remailer>
    <remailing request to Bob encrypted with appropriate remailer  
public key>

    In the final version, this message will be encrypted as well

5) Bank checks x to see if its been used
   Bank sends back to remailer

    ::
    Encrypted: PGP

    <remailing request included in Bob's mail>

    <usage status: used or unused>

6) Bob accepts the "cash"
   Bob sends to bank via anonymous remailer

    ::
    deposit
    <account name>
    <x>
    <C>
    Reply-To: <an anonymous remailer>
    <remailing request for Bob encrypted with appropriate remailer  
public key>

7) Bank checks x, C, account name; if everything OK, deposit
   Bank replies via anonymous remailer

    ::
    Encrypted: PGP

    <remailing request included in Bob's mail>

    <message indicating deposit accepted or rejected>

Alice and Bob may send message to and receive messages from the bank  
via anonymous remailers.  Or more than one...
During the testing/development phase, account names and balances can  
be made public (available via finger command or something like that)  
for verification.
Account names can be hashes of some user chosen string (Email address  
plus random text, etc.)

Customers must be able to 
  choose: two random numbers x, r
  compute: f(x)
           r^3 * f(x) mod n
           f(x)^(1/3) or C^3
  solve: D = C r mod n for C

Bank must be able to
  solve: D^3 mod n for D

So, PGP has routines which can generate random number, calculate  
hashes, and be modified slightly to perform the necessary math.  The  
Bank will be supported by a host of scripts and the math performing  
PGP routines.

Sometime later I will post a run through of the digital bank protocol  
(all numbers and done with Mathematica) as an example for those who  
are interested in an example of the protocol.

Any input or comments or help will be welcome.  Or, if someone else  
is further along than me, I volunteer!  Unfortunately, since the end  
of the semester draws near, I will be unable to work on this very  
much for the next few weeks.  Besides, I've got to go pick up the  
O'Reilly and Associates Perl book to 
move this project along...


---
/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Wed, 2 Dec 92 20:33:22 PST
To: cypherpunks@toad.com
Subject: Re: Suggest splitting things up
In-Reply-To: <9212030000.AA02120@harvey>
Message-ID: <9212030432.AA01759@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



>At  1:22 PM 12/2/92 -0800, John Draper wrote:
>
>>To Cypherpunks:
>>
>>Greetings,  Back on-line again,  after wading through about 225 messages
>>that has accumulated in the last 4 days.   The volume of messages
>>is really getting high,  and perhaps we might want to try and break
>>them up into the following proposed lists.
>
>Sounds like a fine idea.
>

I aggree.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Wed, 2 Dec 92 20:36:57 PST
To: shipley%edev0.Tfs.COM@gateway.Tfs.COM
Subject: Re: Suggest splitting things up
In-Reply-To: <9212030000.AA02120@harvey>
Message-ID: <9212030436.AA01770@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain




I suggest to groups be split as suggested  but I will like to add
that it be donw 

cypherpunks-pgp:	pgp development
cypherpunks-digi-cash:	digital cash

cypherpunks:	cypherpunks-digi-cash cypherpunks-pgp (all of the above)


		-Pete

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx
gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptAZjYXN1
YWy0JlBldGVyIE0gU2hpcGxleSA8c2hpcGxleUBiZXJrZWxleS5lZHU+
=OR9u
-----END PGP PUBLIC KEY BLOCK-----






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Wed, 2 Dec 92 21:14:29 PST
To: cypherpunks@toad.com
Subject: Re: Suggest splitting things up
Message-ID: <9212030513.AA04842@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



>>Greetings,  Back on-line again,  after wading through about 225 messages
>>that has accumulated in the last 4 days.   The volume of messages
>>is really getting high,  and perhaps we might want to try and break
>>them up into the following proposed lists.

>Sounds like a fine idea.

"I aggree."

So do I, but a digest ( 225 / 4 == 56.25 messages per day, concatenated
into one giant digest of messages, sans headers ) would also make the
traffic manageable, while preserving the ability for the various groups
to benefit from one another's divergent, but relevant, insights into the
overall process and its possible applications.

Even if you split the list into multiple 'sub-topical' lists, you'll be
'swamped' with N times the maintenance ( and I suspect maintenance is
already a bit of a hassle, with bounce messages and the like 'deluging'
the hapless administrative staff with a 'rain' of problems ), as well
as 'flooded' with N times as many subscribe and unsubscribe requests ...
and will probably still contemplate a digest format eventually.   (-:

An interactive direct mail option should be preserved, in fact, it would
remain the primary entity ... all that's needed is to add some sort of
alias that evaluates to a queue to the list, then write a script to read
the queue ( with some queue management to avoid race conditions ), strip
out all but trivial header information and '> ' those left behind, and
generate email to those individuals whom have transferred themselves from
the primary alias to the secondary digestifier-and-remailer.

There's a thing called majordomo@greatcircle.com that does this, I think.
I don't know if it's public domain, but it does a lot of this, firewalls
and firewalls-digest are both served by it, and I think it also provides
archival services and such. ( There are others, also. )

My $0.02.


-- richard





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Wed, 2 Dec 92 21:28:56 PST
To: cypherpunks@toad.com
Subject: Re: Suggest splitting things up
In-Reply-To: <9212030436.AA01770@edev0.TFS>
Message-ID: <9212030528.AA25608@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Peter Shipley is one of several people suggesting this list be split
into parts. His specific idea is:

> I suggest to groups be split as suggested  but I will like to add
> that it be donw 
> 
> cypherpunks-pgp:	pgp development
> cypherpunks-digi-cash:	digital cash
> 
> cypherpunks:	cypherpunks-digi-cash cypherpunks-pgp (all of the above)

Splitting the list into "pgp development" and "digital cash" would
take care of the topics being discussed in the _last few days_, but
would do little for the various other "threads du jour" that have
occupied us: one-time pads, dongles, legal issues, key registration,
special purpose chips, etc.

Are we to form a new list each time something fails to fit into one
of the groups suggested?

I think there's a simpler split, should one be needed:

* cypherpunks-technical...writing software, details of dongles, math,
PERL, details of algorithms, PGP development, etc.

*cypherpunks-political...laws, debate, public policy, ethics of
encryption, spread of digital cash, etc.

*cypherpunks-announce....just the announcements of meetings, upcoming
events, important developments, etc.

Now splitting the list means more duplicate messages for those who
subscribe to both (when messages are cross-posted, as some will be),
more "missed" messages when one of the groups is not subscribed to
(resulting in "Can you send me the article....?" thrashing), and some
amount of additional work by the list administrator (Eric Hughes).

Given that a list bifurcation will only buy a savings of 2x in volume
for most people (and many will automatically take both lists), and
given that we all know factors of 2 don't count (:-}), I recommend
against splitting the list.

Besides, you never know what useful stuff will get posted in the group
you don't get. Anybody who chooses to stay ignorant of what the other
group is doing probably won't be able to contribute much to the group
he subscribes to.

--Tim



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Wed, 2 Dec 92 19:49:53 PST
To: cypherpunks@toad.com
Subject: bank protocol run through
Message-ID: <9212030349.AA07296@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



I find it useful to work through a protocol by hand a few times to  
really see what's going on.  Here is an example of the digital bank  
protocol.  It is meant for people who are curious to see if it works,  
as educational material for new subscribers, or general interest.

I'm choosing relatively small numbers to use: in a real  
implementation, they would be much much larger.

OK, let's start!

----------------------------------------
On the bank's side, it chooses the primes
p = 2038074743 and
q = 2038074947
and so the public key n = pq = 4153749073821763621
also phin = Euler totient function of n 

          = (p-1)(q-1) = 4153749069745613932
The bank decides to make people use the exponent 5 (it's just easier  
to tell if GCD[5, phin] is 1)

1) Alice chooses a random x, r.  She hashes x to yield fx
x = 3141526535
r = 5772156649
fx = 2718281828

Here, I just picked the value of the hash function from the  
mathematical air, so to speak.

Alice computes B = r^5 fx mod n
 = (5772156649^5 2718281828) mod 4153749073821763621
 = 592088213321408342 


-> B = PowerMod[r^5 fx, 1, n] in Mathematica

Alice sends B to the bank.

2) The bank takes fifth root of B.  Or, it raises B to the power that  
is the inverse of 5 mod n.
To find the inverse of 5 mod n, compute
inv1 = 5^(-1) mod phin = 5^(-1) mod 4153749069745613932
 = 1661499627898245573

The bank can do this since it knows the factorization of n.

-> inv1 = PowerMod[5, -1, phin] in Mathematica

So, to take the fifth root:
D = B^inv1 mod n 

 = (592088213321408342 ^ 1661499627898245573) mod 4153749073821763621
 = 1189395596986402260

-> D = PowerMod[B, inv, n] in Mathematica

Just as a check: D^5 mod n = 

 = (1189395596986402260 ^ 5) mod 4153749073821763621
= 592088213321408342 = B     So we're OK.
-> Mod[D^5, n] in Mathematica

Bank sends Alice D.

3) Alice extracts C by dividing D by r.  Or, she solves the following  
equation for C:
D = C r mod n, or
1189395596986402260 = C 5772156649 mod 4153749073821763621

This can be solved by multiplying D by the inverse of r mod n, and  
taking the result mod n.  You don't need to know the factors of n.   
As a technical note, there will be only one solution since GCD[D,n] =  
1, which is usually true since n only has two factors p and q.  The  
bank is in trouble if GCD[D, n] != 1 since that means n can be  
factored by the information in D.

inv2 = r^(-1) mod n
 = 5772156649 ^ (-1) mod 4153749073821763621
 = 3900656075651054436

-> inv2 = PowerMod[r, -1, n] in Mathematica

So, C = (D inv2) mod n
 = (1189395596986402260 3900656075651054436) mod 4153749073821763621
 = 3844350519262422248

-> C = Mod[D inv2, n] in Mathematica

Just as a check: C r mod n = 

 = (3844350519262422248 5772156649) mod 4153749073821763621
 = 1189395596986402260 = D     So we're OK.
-> Mod[C r, n] in Mathematica

So now Alice has
x = 3141526535 and
C = 3844350519262422248

4) Alice pays Bob by giving him (x, C)

5) Bob verifies that C = fx ^ (1/5) mod n.  Or, he verifies that fx =  
C^5 mod n
C^5 mod n = 

 = 3844350519262422248 ^ 5 mod 4153749073821763621
 = 2718281828

which does indeed equal f(3141526535) = 2718281828 where f is our  
hashing function.  So Alice isn't cheating by sending a bogus (x, C)

But Bob must also send (x, C) to the bank to verify Alice isn't  
trying to spend the money more than once!
----------------------------------------

So there it is, with numbers and Mathematica statements for those who  
have access to Mathematica.  Hopefully, the numbers are large enough  
to convince people it didn't work out by chance.

Now, the code to perform the math must be written, as well as the  
scripts to support the bank.  Has anyone used the RSAREF routines, or  
should we stick to what's supplied with PGP?  I haven't thought that  
far ahead.  Like I said earlier, I'll pick up work on this in a few  
weeks.

---
/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eli Brandt <ebrandt@jarthur.Claremont.EDU>
Date: Wed, 2 Dec 92 21:57:33 PST
To: cypherpunks@toad.com
Subject: Re: Suggest splitting things up
In-Reply-To: <9212030436.AA01770@edev0.TFS>
Message-ID: <9212030557.AA06522@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> From: Peter Shipley <shipley@tfs.COM>

> I suggest to groups be split as suggested  but I will like to add
> that it be donw 

[ a different way ]

Before we consider splitting the list, we should ask whether there are
a significant number of people who would take less than all of the
sublists.  I really don't know.  If the purpose is just to provide a
way to know what "kind" of message you're about to read, we could use
a "tag" the way sci.v-w does, if we find this necessary.  I personally
don't object to this kind of list volume.

> 		-Pete

   Eli   ebrandt@jarthur.claremont.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: peter honeyman <honey@citi.umich.edu>
Date: Wed, 2 Dec 92 19:29:35 PST
To: cypherpunks@toad.com
Subject: uh oh, o-o
Message-ID: <9212030329.AA03885@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


the following remarks were transcribed from today's live satellite
broadcast from sun on object oriented technologies, hosted by john
gage.  in his introductory remarks, he said:

    I found something else that a number of you probably have read already,
    it's in a way relevant to this, about searching through large archives.

    This is John Gilmore, Sun employee number five.

    [Holding up to the camera last Saturday's NYT article.]

    This is John in his normal confrontational stance with the National
    Security Agency.

    John wanted two textbooks on cryptanalysis that were classified, then
    declassified briefly, then reclassified.

    Using good search techniques, using what Bob Kahn would call "knowledge
    robots" or "knowbots", objects searching for your bibliographic material
    on the net, John found them in a public library and that made the NSA
    very upset.

    For about three days there was a fight, this was in Saturday's New York
    Times, there was a fight until Tuesday of this week, yesterday, they
    declassified these books.

    So using object technology in some rough sense to pore through enormous
    amounts of information is a topic that may sound futuristic but it's
    very, very real, we think, and we'll talk about that.

enjoy.

	peter




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: crunch@netcom.com (John Draper)
Date: Wed, 2 Dec 92 22:38:55 PST
To: tcmay@netcom.com
Subject: Re: Suggest splitting things up
Message-ID: <9212030638.AA03477@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


I recommend that we adopt Yim May's idea for how the mailing lists
are split up.   BTW,  if that ever happens,   I only want to me
on the cypherpunks-technical,  and cypherpunks-announce mailing
lists.

Cheers
JD




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Fan Li TAI <UFLTAI%MEMSTVX1.bitnet@CUNYVM.CUNY.EDU>
Date: Wed, 2 Dec 92 21:50:52 PST
To: cypherpunks@toad.com
Subject: enjoy enjoy
Message-ID: <9212030550.AA06424@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Hiya,
        Below's something I found...  I know you all have been swamped with
mail... but this one is in the spirit of things, I think...  Found it in
Life...

____begin____
From: sherman@.cs.umbc.edu (Dr. Alan Sherman)
Subject: Superpolylogarithmic Subexponential Functions
Newsgroups: rec.music.dementia

Announcing: Technical Report TRCS-91-17, University of Maryland
Baltimore County.  A preliminary version of this paper appeared in two
parts in {\it SIGACT News}, {\bf 22}:1 (winter 1991), Whole Number~78,
65--73, and {\bf 22}:2 (spring 1991), Whole Number~79, 51--56.


        On Superpolylogarithmic Subexponential Functions

                        Alan T. Sherman
                Computer  Science Department
                University of Maryland Baltimore County
                Baltimore, Maryland 21228
                        and
                Institute for Advanced Computer Studies
                University of Maryland College Park
                College Park, Maryland 20742

                June 21, 1990 (revised April 1, 1991)


                        Abstract

A superpolylogarithmic subexponential function is any function that
asymptotically grows faster than any polynomial of any logarithm but
slower than any exponential.  We present a recently discovered
nineteenth-century manuscript about these functions, which in part
because of their applications in cryptology, have received
considerable attention in contemporary computer science research.
Attributed to the little-known yet highly-suspect
composer/mathematician Maria Poopings, the manuscript can be sung to
the tune of ``Supercalifragilisticexpialidocious'' from the musical
Mary Poppins.  In addition, we prove three ridiculous facts about
superpolylogarithmic subexponential functions.  Using novel extensions
to the popular DTIME notation from complexity theory, we also define
the complexity class SuperPolyLog/SubExp, which consists of all
languages that can be accepted within deterministic
superpolylogarithmic subexponential time.  We show that this class is
notationally intractable in the sense that it cannot be conveniently
described using existing terminology.  Surprisingly, there is some
scientific value in our notational novelties; moreover, students may
find this paper helpful in learning about growth rates, asymptotic
notations, cryptology, and reversible computation.

Keywords. Algorithms, asymptotic notation, complexity theory,
cryptography, cryptology, DTIME, mathematical humor, Maria Poopings,
Mary Poppins, musical computer science, reversible computation,
Supercalifragilisticexpialidocious, superpolylogarithmic
subexponential functions, SuperPolyLog/SubExp.

                --- lyrics ---

            Superpolylogarithmic Subexponential Functions
    (Sung to the tune of ``Supercalifragilisticexpialidocious.'')

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

Superpolylogarithmic subexponential functions!
Faster than a polylog but slower than exponential.
Even though they're hard to say, they're truly quintessential.
Superpolylogarithmic subexponential functions!

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

For Alice to send a message through to Bob when Eve's eavesdropping,
do use a trapdoor one-way function---not a one-key mapping.
First take a message x, let's say, and raise it to the e;
then mod it out by p times q but keep these secretly.  Oh!

(Chorus)

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

The process takes but poly-time and appears to be secure:
why even just a single bit is one over polylog pure.
Though Alice thinks that Eve must spend time at least exponential,
by using Lenstra's elliptic curves, Eve splits n subexponentially.  Oh!

(Chorus)

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

we remove the heat with water but there's a better strategy.
Since thermodynamics does not apply when info is not doomed,
the laws of physics don't require that power be consumed.  Oh!

(Chorus)

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

Now Bennett said in `73, to run a program P,
you simulate the program P, but do so reversibly.
The problem with this method is that space is exponential,
so trade off time to save on space---this really is essential! Oh!

(Chorus)

Um diddle diddle diddle, um diddle ay!
Um diddle diddle diddle, um diddle ay!

Did you know if you invert one, you get a
funtionential subexporithmic logapolyrepus?
But that's quite a singularity!  So,

If you are in an oral exam and cannot find the way,
just summon up these words and then you've got a lot to say.
But better use them carefully or you could fail the test.
A professor once asked me,
``What do you call functions that grow faster than any
polylogarithm but slower than exponential?'' There're,

Superpolylogarithmic subexponential functions!
Superpolylogarithmic subexponential functions!
Superpolylogarithmic subexponential functions!
Superpolylogarithmic subexponential functions!

                --- end of lyrics ---

Note: See paper for detailed performance notes and mathematical
proofs by anagramming.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@rebma.rebma.mn.org
Date: Wed, 2 Dec 92 22:44:26 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <m0mx9a9-0005l0C@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


Here's a new look for electronic cash.  Instead of having a bank where
people have accounts, have the "banker" be a money changer.  He
changes Federal Reserve Notes into crypto dollars.  Anybody can send
him dollars, and include an email address and public key, and he will
email them that same amount of electronic cash.  Anybody can email him
electronic cash, and include a snail-mail address, and he will send
them that same amount of U.S. dollars.

You don't have a permanent relationship with him, you just use the
service when you need to change between electronic and paper dollars.

With the Chaum cash that was discussed here a while ago, where you
need to "deposit" it right away when you get it, here's what you could
do instead.  Send it to the money changer, and ask for fresh crypto
cash back.  It's like you combined a "deposit" with an exactly equal
"withdrawal".  What you get back is good cash that you can hold or
spend as needed.  There are no account numbers involved, no demand
deposits, no bank account at all.

Eric Hughes mentioned demand deposits as defining a bank, so maybe
this would be a way around that.

--
Mr. Money
--





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Mitra <mitra@pandora.sf.ca.us>
Date: Wed, 2 Dec 92 16:27:35 PST
Subject: Re: Suggest splitting things up
In-Reply-To: <9212022122.AA16492@netcom2.netcom.com>
Message-ID: <BynqKt.IDI@pandora.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



I've had this list gatewayed into a newsgroup locally since it started, 
as long as people are reasonably disciplined (what us, disciplined) about
keeping the same subject line, then the volume of this list is quite managable.
OTOH - there is no way I could have handled this volume in my regular mailbox.

- Mitra

-- 
Mitra                                                  mitra@pandora.sf.ca.us
Technical Director, Pandora Systems                    (415)488-0944




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "DrZaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Thu, 3 Dec 92 07:38:03 PST
To: cypherpunks@toad.com
Subject: RE: digital banking, file formats, etc.
Message-ID: <19286.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


In Message Wed, 2 Dec 92 20:17:19 -0600,
  Karl L. Barrus <tree.egr.uh.edu!barrus@netcomsv.netcom.com> writes:

>1) Alice chooses x, r
>   Alice computes B = r^3 * f(x) mod n
>   Alice sends the following message to the bank via an anonymous
>remailer
>
>    ::
>    withdraw
>    <account name>
>    <B = r^3 * f(x) mod n>
>    Reply-To: <an anonymous remailer>
>    <remailing request to Alice encrypted with appropriate remailer
>public key>
>

     What happens if the bank mails $$$ to Alice.  Somebody intprive Alice of HER money.  I havn't read much about digital money
protocols so correct me if I'm wrong. TTFN!
DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nraizman@winchester.pp.psc.edu
Date: Thu, 3 Dec 92 08:34:29 PST
To: cypherpunks@toad.com
Subject: Info Wanted
Message-ID: <9212031629.AA08600@winchester.pp.psc.edu>
MIME-Version: 1.0
Content-Type: text/plain


Wiggidi-wiggidi-whassup?
I'm new here, and , while I can follow the digital money threads, and
otehr such things, I am lost when it comes to this PGP and Public Key
stuff. Could someone please explain it to me? 
Thanx a lot!
nraizman@winchester.pp.psc.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: andrew_derry@sfu.ca
Date: Thu, 3 Dec 92 12:07:53 PST
To: cypherpunks@toad.com
Subject: Re: digest (not splitting)
Message-ID: <9212032007.AA24537@whistler.sfu.ca>
MIME-Version: 1.0
Content-Type: text/plain


Richard Childers <rchilder@us.oracle.com> says:
>So do I, but a digest ( 225 / 4 == 56.25 messages per day, concatenated
>into one giant digest of messages, sans headers ) would also make the
>traffic manageable, while preserving the ability for the various groups
>to benefit from one another's divergent, but relevant, insights into the
>overall process and its possible applications.

I'm for the digest format.  Should make it much more managable.

---
Andrew Derry                      |
ACS@HCC - Simon Fraser University |
Internet: derry@sfu.ca            |





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "DrZaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Thu, 3 Dec 92 16:08:48 PST
To: cypherpunks@toad.com
Subject: Re: Suggest splitting things up
Message-ID: <47824.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


In Message Wed, 2 Dec 92 21:56:54 PST,
  Eli Brandt <jarthur.Claremont.EDU!ebrandt@netcomsv.netcom.com> writes:

> I personally don't object to this kind of list volume.

    Neither do I, just to cast my vote in the hat.  In fact, I don't even
think that we need to tag the messages for the type of content.  I'm
interested in anything that is posted in this list and read every message.
TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Thu, 3 Dec 92 11:21:49 PST
To: ncselxsi!drzaphod@ncselxsi.netcom.com
Subject: Re: digital banking, file formats, etc.
In-Reply-To: <19286.drzaphod@ncselxsi>
Message-ID: <9212031921.AA09706@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



Dr. Zaphod writes:
>What happens if the bank mails $$$ to Alice.  Somebody intprive
>Alice of HER money.  I haven't read much about digital money protocols
>so correct me if I'm wrong. TTFN!

Well,

I intend for the communications themselves to encrypted as well.  This
would call for the remailing request to also somehow include Alice's
public key, and Bob's communications to include his public key, etc.
This will prevent intercepted mail from tampering and keep the
anonimity.  .  Possibly the bank will have two public keys: one for
money, and one for mail.

However, in the initial phase to keep things simple, the messages
won't be encrypted - only the remailing info will.  This will
implement the anonymous part, and allow transactions, but will provide
no protection against intercepting mail, etc.  Heck, the initial
system will only allow withdrawals and deposits of a constant
denomination, so I'll worry about spoofing later :-)

I'm operating under the premise of getting something out that is
usable but not full blown.  So extra denominations, fully encrypted
messages, etc. will be added later.

Also, I received a mail from rjc@gnu.ai.mit.edu (Rob Crowley?) - whose
mail I seem to have misplaced - voicing concern over proving deposits in
the event that the bank can't be trusted.  Any of the digital currency
protocol articles discuss this issue?  I guess I need to visit the
library again and do some more research, after finals.

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Thu, 3 Dec 92 18:36:43 PST
To: cypherpunks@toad.com
Subject: Re: digital banking
Message-ID: <9212040022.AA15172@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


I enjoyed seeing Karl's walk-through of Chaum's digital cash
algorithm.  The numbers looked right.  One point is that doing
different denominations isn't that much harder, you just need to have
more exponents.  As you generate your primes p and q, make sure that
p-1 and q-1 aren't divisible by any small primes (other than 2).  This
will ensure that phi = (p-1)(q-1) is not divisible by small primes, hence
that gcd(e, phi) will be 1 for those same small primes, in fact for
all the odd numbers.

Karl also quoted a comment from Ray Cromwell expressing concern over
proving deposits.  Ideally you'd get a signed receipt from the bank
for every deposit you make.  In the case of electronic deposits, there
exist protocols for "gradual secret exchange" that might be suitable
for this purpose.  What you'd like is to send the bank your deposit
"gradually", while the bank simultaneously gradually sends you a
digitally signed receipt.  I don't recall the details of these
protocols.  Gradual exchange would not be very convenient for email
because of the long turnaround times in mail systems, but if you had a
better connection it might be useful, especially for large deposits.

Another way to look at it is, what stops the local merchant from
taking your payment, putting it in his pocket, and then denying that
you've given him anything?  It would just be his word against yours.
One answer is, if he does that to multiple people, their multiple
stories would have more credibility than his denials.  Similarly, a
bank which made a habit of cheating its customers would find itself
publically exposed.  So it may be reasonable to trust the bank for
routine transactions.

Hal
74076.1041@compuserve.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Thu, 3 Dec 92 15:36:23 PST
To: cypherpunks@toad.com
Subject: understandable cypher software
Message-ID: <9212032155.AB19933@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


Folks--

A paragraph of philosophy and then some technical PGP questions.

I should be able to verify with my own eyes how cypher technology works.  
Otherwise I'm trusting my security to somebody's black box.
I should be able to write my own and test that it interacts with someone 
else's the way it's supposed to.  I should be able to monitor the 
communications between my copy of a cypher product and some other, and 
verify that they're doing the things people say they are. 
Besides, I'd like to carry the crypto basics in my head "just in case."
To these ends, I'd like cypher software that is as easy to read and
understand and trust as possible.  I'd like to start with a distilled PGP.  

Does this list cover the heart chambers of PGP? (Not to devalue the rest):
        RSA
        IDEA
        The signature algorithm (MD5?)
                128 bits?
                Is that based on RSA?
        A cryptostrong pseudorandom # generator?
                Is this based on RSA?
        Something that takes keystroke delays (real, but not so good, 
                random numbers) and makes real good random numbers?
                Is this based on RSA?
        A data compression algorithm (some variation of LZW?)
        A binary<-->ascii translator

RSA seems to depend on doing modulo-multiply on big integers.  What are the 
relative speeds of the different modmults in PGP (modulo processor speed)...
        the simplest C version
        the fastest C version
        the fastest assembler version on the processor where it matters least
        the fastest assembler version on the processor where it matters most?

Given the time to do modmult, couldn't all the rest (including modexp) be
done in an interpreter that had big ints and modmult as a primitive?

What's the formula for RSA again?
        out = in * something ^ somethingelse mod yetanother??
        I know it can't be, because the key is only one number.

What is/are the basic primitive(s) for IDEA?

-fnerd
"Computer software must not only work, it must also appear to work."
                           --Carl Hewitt
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 3 Dec 92 18:31:36 PST
To: cypherpunks@toad.com
Subject: FTP site
Message-ID: <9212040228.AA26580@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



We have an anonymous FTP site.  It's at soda.berkeley.edu.  The
directory is pub/cypherpunks.  Right now there's not much in it.  A
few miscellaneous documents are in the misc/ directory.  There's an
empty directory for listings of ftp sites in other places that hold
crypto software of various forms.

But most importantly the source code to the remailer as currently
running is in there.  I'd like to see even more remailers than three.
And if you can't put up a remailer (because, to take one of the few
good examples, you don't run Unix) I'd still like people to study the
code.

We'll eventually have weekly digests of mail traffic from the list,
but those aren't created yet.

Enjoy!

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 3 Dec 92 18:35:51 PST
To: cypherpunks@toad.com
Subject: Suggest splitting things up
Message-ID: <9212040235.AA27065@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



A word on the subject of altering the list from the list maintainer.

There's been lots of discussion about splitting up the list into
various pieces.  In a word, it's not going to happen.

Look, this is the cypherpunks list.  Cypherpunks write code.  A
corollary to this is that cypherpunks take responsibility for the
volume of mail they receive.  If you're getting too much mail, use a
filter.  Many of you may not know that the remailer software as
currently configured pressed into service just such a filter.

In the just-announced ftp site, there's the source code, in perl, to
just such a filter.  You can change it to do whatever you like.  In
particular, you can install it to filter all your cypherpunks mail to
a separate mailbox, file, or subdirectory.

You can also use MH, whose slocal the above perl filter was based on.
slocal can filter all of your cypherpunks mail to separate places.

You can also send all of your cypherpunks mail to a separate directory
and use a newsreader to read it.  I've never done this, but certain
list members have.  If one of them (say, Mitra, who recently mentioned
that he does this) would post a short summary of how it's done to the
list and offer to answer questions off-line, I'd appreciate it.

Eric




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Thu, 3 Dec 92 15:53:18 PST
To: fnerd@smds.com
Subject: re: understandable cypher software
In-Reply-To: <9212032155.AB19933@smds.com>
Message-ID: <9212032352.AA02808@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


>> RSA seems to depend on doing modulo-multiply on big integers.  What are the 
>> relative speeds of the different modmults in PGP (modulo processor speed)...
	Also consider reliability. As of 2.0, modmult on the SPARC
(using the MERRITT code) fails on some keys, while either the PEASANT
or UPTON routines function correctly but are slower. (I haven't had
time to test them in parallel and find where they diverge, but there
is a large keyring "out there" that breaks the MERRITT code in several
places...)
	(on the main thread, yes, understanding "the whole thing" is a
good idea, and perhaps modifying the code to make this easier is a
useful development goal...)
								_Mark_




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: cordones@IMAGE.CS.NYU.EDU (Deus Ex Machina)
Date: Thu, 3 Dec 92 16:29:18 PST
To: cypherpunks@toad.com
Subject: Brand-spanking new key
Message-ID: <9212040026.AA29192@IMAGE.CS.NYU.EDU>
MIME-Version: 1.0
Content-Type: text/plain


Hello everyone.
I just finished installing PGP2.0 in a rush...so..here goes my 
1024-bit Military grade (he..guess I am a little paranoid..) key.
Give it a try and perhaps I will experience some ESP...

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisdxzYAAAEEALaDepo7QeCT2MCu+02nGuAZIJtoRwbxlwulUT/SehKH7xFW
43UqHZKHwMjDT5S8TESpGLtanhKsgmGa+Pp1X/tEImS2CqEvnPQhy0mjQMqR1WZ7
NfKenvUesXkE6pTpg/8Fk1AwsqRiypUEHoiNeU4k14gceilSg2Z/lrxl5FyxAAUR
tCNFbCBab3JybyA8Y29yZG9uZXNAcm9ib2NvcC5ueXUuZWR1Pg==
=o+Oh
-----END PGP PUBLIC KEY BLOCK-----



so..have phun...

El Zorro




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 4 Dec 92 03:10:36 PST
To: cypherpunks@toad.com
Subject: Re:  enjoy enjoy
Message-ID: <199212041109.AA24355@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Great one...!

When I was taking undergrad social science stats, I came up with a similar
one, just one verse though...

Pearson-product-moment-correlation coefficients!
If you still can't get it then you're mentally deficient
Is this really learning or selection by attrition?
Pearson-product-moment-correlation coefficients!

-gg




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Mitra <mitra@pandora.sf.ca.us>
Date: Thu, 3 Dec 92 19:36:42 PST
Subject: Re: Suggest splitting things up
In-Reply-To: <9212040235.AA27065@soda.berkeley.edu>
Message-ID: <Byptzn.6J9@pandora.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Sure Eric, 

I'm on SCO unix (i.e. non compatible with everyone else - I cant even 
get perl running yet), I've added the following lines to my .maildelivery

To	cypherpunks@toad.com	|	A	inews -0 -a list -n list.cypherpunks
Cc	cypherpunks@toad.com	|	A	inews -0 -a list -n list.cypherpunks
Apparently-To	cypherpunks@toad.com	|	A	inews -0 -a list -n list.cypherpunks

This catches the three most common address headers, unfortunately the
mailing list at cypherpunks doesnt behave like a well-behaved reflecter
should and put its own address in the header (most would add "Sender:
cypherpunks@toad.com")

All this does is pipe messages that match the headers into inews with the args
following. Those args are:

-0	An extension I added, which makes inews always return 0 (otherwise
	our braindead delivery agent "mmdf" cycles forever trying to deliver
	bad messages and creating a HUGE dead.article.	
-a list	Add an "Approved: list" line so that inews will post it to a moderated
	newsgroup
-n list.cypherpunks	Stick it in the newsgroup "list.cypherpunks"

list.cypherpunks is set up moderated, with the moderater being 
cypherpunks@toad.com

Happy gatewaying, if someone has a better way of doing this then let me 
know.

- Mitra


-- 
Mitra                                                  mitra@pandora.sf.ca.us
Technical Director, Pandora Systems                    (415)488-0944




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Fri, 4 Dec 92 09:55:49 PST
To: cypherpunks@toad.com
Subject: PGP questions
Message-ID: <9212041752.AA17033@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


It's probably good to discuss how PGP works here, for educational
purposes, but I would expect people to get the source code if they
really are interested.  I can give some pointers here to answers to
some of the questions people have asked.

Steve Witham asks several questions.  I think the crypto glossary
which Tim posted a couple of weeks ago tells how RSA works, so I won't
reiterate that here.  Steve, if you didn't get it, maybe Tim could
send it to you.

PGP's signature algorithm creates an MD5 message digest of the
message, then signs that digest by raising it to the secret exponent
"d", mod "n".  MD5 is a public-domain message digest algorithm created
by RSA Data Security, Inc, which breaks messages into blocks of 64
bytes as input and produces a 16-byte (128-bit) digest.  PGP then pads
this 16-byte number to be about the size of n, and does the
exponentiation.

PGP does not do its decryption/signature exponentiation by actually
raising the number to the power of d mod n, but by doing a
mathematically equivalent operation involving two exponentiations, one
mod p and one mod q.  Since p and q are half the length of n, and
exponentiation takes roughly the third power of the number of bits in
the modulus, this reduces the amount of time by a factor of 4.

The random number generator has several different modes, and I can
only suggest looking at random.c.

The data-compression algorithm is not really relevant but is based on
zip.  The binary-ascii translator is also not important but is a
variant on the PEM standard.

Steve asks a lot of questions about the speed of different versions.
Maybe asking on alt.security.pgp would produce some representative
values.  I'm not sure whether anyone has a database with all these
numbers.

I understand that PGP 2.1 may have a faster version of the Upton
modmult.  Preliminary timings suggest that it's still slightly slower
than the Merritt modmult on the Sparc, but if Merritt really is
unreliable (I haven't heard about this) then switching to Upton will
not involve much of a penalty.  PGP is very fast on Sparcs anyway and
I don't think making it 10% slower would matter.

Profiling indicates that yes, during the RSA encryption phase, most of
the time is spent in modmult.  An interpreter could be built to do a
modular exponentiation using a C implementation of modmult and it
would be about as fast.  However, that still leaves the generation of
the random session key, padding it with random numbers so that it is
suitable for RSA operations, converting the RSA-encrypted session key
into a format suitable for writing to a file, doing the IDEA
encryption, wrapping this all up with control information so that it
can be decrypted, looking up key information from a key ring file or
some other data file (possibly decrypting it on the fly), converting
to ASCII, etc.  All these are part of an encryption/decryption cycle
and can't really be skipped.

Hal
74076.1041@compuserve.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Fri, 4 Dec 92 10:03:39 PST
To: cypherpunks@toad.com
Subject: Re: Weakness of the PGP scheme ?
Message-ID: <9212041755.AA17036@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Vanguard@gribb.hsr.no asks about trying all the IDEA keys.  If you
will look in idea.h you will see that the IDEA key is 16 bytes long,
which is 128 bits.  This is long enough to make trying them all
impossible.  Trying to predict one IDEA key by knowing the previous
one also looks hard, as PGP basically cycles IDEA on random input and
takes the output as the keys.  If you could predict this output it
would be similar to breaking IDEA.

On the other hand, PGP normally keeps its random information in a
small file called randseed.bin.  It uses the contents of this file
plus the current time of day in seconds as the input to generate the
IDEA key.  If you stole this file from someone (it's not
cryptographically protected, unlike the secret key ring), and you know
within several hours or a day when he sent each message, you could
probably calculate all possible IDEA keys in a feasible amount of time
(by trying all plausible values for the time of day in seconds).  This
would also let you calculate the new contents of the randseed.bin
file.  As long as you didn't miss any messages he sent, you could keep
doing this and break all of his outgoing messages.

You can prevent this by removing your randseed.bin file and
substituting an empty file (or one that is less than 16 bytes long) in
its place.  This will cause PGP to prompt you for random keyboard
input each time you send a message, which would make it impossible for
the attack above to work.  It would mean less convenience, though.

The relevant routines are make_random_ideakey() and
strong_pseudorandom() in crypto.c, as well as the code in random.c.

Hal
74076.1041@compuserv.ecom




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Sat, 5 Dec 92 14:51:16 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: First digital money?
Message-ID: <5Ps0uB3w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


Following cross-posted from Extropians:
 
To: gnu.ai.mit.edu!Extropians
Date: 02 Dec 92 11:31:59 EST
From: Duncan Frissell <szebra!CompuServe.COM!76630.3577>
Subject: If I only had $100K
 
 
Bankers Trust has started a Global Settlement Fund to allow securities traders
to make free funds transfers 24 hours a day.  The Chicago Mercantile Exchange
now accepts GSF shares in addition to cash and T-bills for settlement purposes.
 
GSF shares will pay interest and there are no transactions charges for
transfers.  For now, the account minimum is $100,000 and participating
institutions must have a link to Bankers Trust's New York operations center.
The company plans to open similar funds denominated in Yen and Pounds Sterling.
It also plans a BBS system which will allow traders to arrange forex exchanges
with the holders of other currency shares 24 hours a day.
 
Bankers Trust has targeted the Fed Wire that does 60 million transactions worth
$200 billion a year but is slow and expensive.
 
Now once such a system reaches the *retail* level we'll really have something.
 
Duncan Frissell
 
*******************************************************************************
* DUNCAN FRISSELL                        Attorney at Law, Writer, and Privacy *
* CIS 76630,3577                         Consultant since the Nixon           *
* Internet 76630.3577@compuserve.com       Administration                     *
* Easylink 62853962                                                           *
* Attmail !dfrissell                                                          *
* TLX:  402231 FRISSELL NYK                                                   *
*                                                                             *
*          * Clinton Inaugural Sale - Any Question Answered for $9.99 *       *
*                                                                             *
*******************************************************************************

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Fri, 4 Dec 92 03:39:29 PST
To: cypherpunks@toad.com
Subject: Chosen cryptotext and RSA
Message-ID: <1992Dec4.102619.25216@extropia.wimsey.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain


Can chosen crypto-text break RSA?  (I.e., having access to the
decryption machine - as a black box and finding the decryption
exponent.)
-- 
	Miron Cuperman <miron@extropia.wimsey.com>  | NeXTmail/mime ok
		       <miron@cs.sfu.ca>	    | Public key avail
	AMIX: MCuperman				    |
cybercomputingimmortallaissezfaire		    |




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Fri, 4 Dec 92 10:02:46 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9212041802.AA13345@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain


FutureNerd Steve Witham writes:

>I should be able to verify with my own eyes how cypher technology works.  
>Otherwise I'm trusting my security to somebody's black box.

This is important, which is why its nice to have source code.
However, be prepared to invest a little :-) time in the study of PGP's
code; I recently printed it out and must have sucked a toner cartridge
nearly dry as it took more than 500 pages!  Check out 'wc -l *.[ch]'
which results in 22720 lines for me.

>        The signature algorithm (MD5?)
>                128 bits?
>                Is that based on RSA?

Get the md5.doc from rsa.com - available via anonymous ftp.  It
explains the algorithm (which is largely bitwise operations on blocks
of the input stream) and even includes source code.

>        A cryptostrong pseudorandom # generator?
>                Is this based on RSA?

Somebody posted a cryptographically strong prng to sci.crypt recently,
but I haven't had a chance to look it over.  I have my own rng - a ten
sided die, which I haven't had occasion to use, yet.  

>        A binary<-->ascii translator

Phil Karn's DES package includes source code for uuencode, which
performs this translation.  I'm sure it is somewhere in the PGP code
as well.  There is also RFC 1113.

>What's the formula for RSA again?
>        out = in * something ^ somethingelse mod yetanother??
>        I know it can't be, because the key is only one number.

Close!  That looks like the formula for solving ax mod n = d for x
given a, n, d.

RSA: pick two primes p and q.  Then n=pq.  As Hal Finney said, the two
primes should be "good" in the sense that p-1 and q-1 have no small
prime factors.  Obviously, you can't avoid having 2 divide p-1 and
q-1, but that should be about it.  Also, p and q should differ in
length by a few digits otherwise an enemy may begin to try factoring n
by starting near sqrt(n).

Pick a decryption exponent d.  d and phi(n) should be relatively
prime, where phi(x) = Euler totient function = # of numbers less than
x which are relatively prime to x = x-1 for x prime.  For n, phi(n) =
(p-1)(q-1).  Calculate the inverse of d mod phi(n) and call it e, your
encryption exponent (e = d^(-1) mod phi(n)).  Publish n and e as your
public info, and keep d secret as your decryption key.

Somebody encrypts a message by calculating M^e mod n.  You decrypt the
ciphertext by calculating C^d mod n.

For example: p=7, q=11 => n=77 and phi(n)=60.
I pick d=13, gcd(13,60) = 1 so it is acceptable.
Then e = 13^(-1) mod 60 = 37.  Check: 13 37 mod 60 = 1.
A message M=20 is encrypted as 20^37 mod 77 = 48.
I decrypted the ciphertext 48 like this: 48^13 mod 77 = 20, and I got
back the original message.

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 4 Dec 92 09:43:36 PST
To: VANGUARD@gribb.hsr.no
Subject: Weakness of the PGP scheme ?
In-Reply-To: <MAILQUEUE-101.921204152203.416@gribb.hsr.no>
Message-ID: <9212041720.AA05323@newsu.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: VANGUARD@gribb.hsr.no

>The underlying security of the PGP scheme is based on two different
>systems, the RSA asymetric cipher and the IDEA cipher. For standard
>encryption the plaintext is encrypted with a IDEA using a "random"
>key, then the key is communicated using RSA. Then we have two direct
>ways of analysing a message, we might have a run a plaintext attack
>on the ciphertext trying out all possible IDEA keys which will tak
>a lot of effort, or we might break the RSA key to get the IDEA key.

>But I propose an easier attack; Using a Encrypted Ciphertext together
>with the public key used for encryption, It would be possible to run
>a trial encrypting all possible IDEA keys using the RSA public key
>and compare it with the encrypted IDEA key, if a match is found then
>you have the IDEA key for this one message. Using an RSA chip that is
>capable of performing exponetsiations VERY fast I dont think that
>this would be unfeasable.

This is quite wrong. This only makes sense if RSA were inherently much
faster than IDEA. In fact, IDEA is orders of magnitude slower than
RSA; thats the whole reason that we use IDEA session keys encrypted
with RSA and not RSA itself to encrypt the message -- RSA is way too
slow. The result of this is that trying all possible IDEA keys
directly to break the cypher is far far faster than trying to encrypt
all possible IDEA keys with RSA. Now, since the security of IDEA
depends on it being secure from brute force attacks like trying all
possible IDEA keys and seeing which one produces a good message, the
result is that if IDEA is secure, PGP is certainly secure from the
attack you mention.

>The most important factor in this attack is the length of the IDEA
>key. But another concern is the generation of the IDEA key, is it
>possible knowing the value of the RANDSEED to know all the subsequent
>IDEA keys?, or would knowing the last IDEA key drastically reduce the
>time needed to search for a subsequent one?

If the random number generator is good, then it should not be possible
to predict the next session key. If it is bad, all bets are off. I
would agree that questions of the quality of the RNG have been
inadequitely explored.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Fri, 4 Dec 92 13:23:43 PST
To: cypherpunks@toad.com
Subject: Sources of Crypto Information
In-Reply-To: <9212040228.AA26580@soda.berkeley.edu>
Message-ID: <9212042123.AA12247@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Cypherspace Residents,

Several people have asked about what PGP is, how RSA works, what
digital cash is all about, etc. I'll recap where and how these
questions can be answered.

1. Long term, there will be a FAQ, to be coordinated by Hugh Daniel,
who recently posted about this.

2. I posted or mentioned the following items to this list very recently:

- Crypto Glossary (which explains, albeit briefly, RSA, digital cash,
DC-Nets, PGP, etc.). This has been also been submitted for the
anonymous ftp site (at soda.berkeley.edu in pub/cypherpunks).

- Larry Loen's crypto FAQ he posted to sci.crypt recently. This was
also submitted for the  ftp site.

3. The documentation for PGP has a good discussion of the issues, how
the IDEA cipher works, etc. Read this, please, before asking the
entire list how RSA works.

4. "Cypherpunks read crypto books" is my variant of Eric's
"Cypherpunks write code." (No point in trying to write code if you
don't have any idea what you're doing.) I've described many excellent
books and articles. Almost any recent book will give you an excellent
list of other books.

5. Hal Finney and Karl Barrus have both written excellent summaries
of how digital cash works. Work through their examples! (A personal
note: I'm blissfully PERL-illiterate, but I use Mathematica on my Mac,
so Karl's examples in Mathematica overjoyed me!)

6. Several weeks ago I posted some articles on the dining
cryptographers protocol, as Hal also did. I can send these to anyone
who wasn't on the list then. (Ditto for the Crypto Glossary.)

7. Sci.crypt is worth reading, especially if you have a good
newsreader like "tin" which allows interesting threads to be quickly
identified. 

Hope this helps.

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: VANGUARD@gribb.hsr.no
Date: Fri, 4 Dec 92 06:18:02 PST
To: cypherpunks@toad.com
Subject: Weakness of the PGP scheme ?
Message-ID: <MAILQUEUE-101.921204152203.416@gribb.hsr.no>
MIME-Version: 1.0
Content-Type: text/plain


To my knowledge there is done very little cryptographical anlysis on
the PGP protocol, and just recently I saw I possible weak point in
the PGP scheme.

The underlying security of the PGP scheme is based on two different
systems, the RSA asymetric cipher and the IDEA cipher. For standard
encryption the plaintext is encrypted with a IDEA using a "random"
key, then the key is communicated using RSA. Then we have two direct
ways of analysing a message, we might have a run a plaintext attack
on the ciphertext trying out all possible IDEA keys which will tak
a lot of effort, or we might break the RSA key to get the IDEA key.

But I propose an easier attack; Using a Encrypted Ciphertext together
with the public key used for encryption, It would be possible to run
a trial encrypting all possible IDEA keys using the RSA public key
and compare it with the encrypted IDEA key, if a match is found then
you have the IDEA key for this one message. Using an RSA chip that is
capable of performing exponetsiations VERY fast I dont think that
this would be unfeasable.

The most important factor in this attack is the length of the IDEA
key. But another concern is the generation of the IDEA key, is it
possible knowing the value of the RANDSEED to know all the subsequent
IDEA keys?, or would knowing the last IDEA key drastically reduce the
time needed to search for a subsequent one? So far I haven't studied
PGP enough to answer all these questions.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: norm@netcom.com (Norman Hardy)
Date: Fri, 4 Dec 92 15:51:08 PST
To: cypherpunks@toad.com
Subject: Re: digital banking
Message-ID: <9212042350.AA21011@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


As I understand Chaum's Digi-Cash scheme the bank customer is 
protected both against bank fraud and merchant fraud but not 
against collusion between the two. The customer need not be 
unknown to the bank in order that her purchases with bank notes be 
unknown to the bank. This is where blind bank signatures come in. 
Neither need the merchant be unknown to the bank. Remailers are 
unnecessary to hide connection between the merchant and his 
customers. The bank knows both but has no way to associate them.
 
This being the case, the bank customer is protected against a 
false denial of deposit. When one deposits Digi-Cash in a bank he 
presumably waits for an indication from the bank that the cash was 
still valid (not previously deposited). The customer retains this 
indication as a receipt which is signed by a private bank key. A 
bank's positive reputation is useful but not necessary at this 
point.
 
Another concern is the false denial of payment by the merchant. If 
the merchant's customer is willing to reveal to a judge that she 
paid the merchant, and she retained the note with which she paid, 
and the bank retains a record of the merchant's deposits then she 
can argue that it was she that caused the bank to mint the note 
since only the person for whom the note was minted and the 
merchant who had cashed it (and the bank) should know its bits. 
This would require that the bank respond to the judicial query 
"has bank customer M deposited note x?".




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Fri, 4 Dec 92 17:04:59 PST
To: cypherpunks@toad.com
Subject: usenix
Message-ID: <9212050104.AA18056@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



A list for discussion of the crypto-bus to usenix has been formed.  To join,
send mail to usenix-crypto-bus-driver@soda.berkeley.edu.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@cs.Buffalo.EDU
Date: Fri, 4 Dec 92 17:32:06 PST
To: cypherpunks@toad.com
Subject: Another remailer
Message-ID: <9212042350.AA10597@armstrong.cs.Buffalo.EDU>
MIME-Version: 1.0
Content-Type: text/plain


I have set up another reamiler... the address is babani@cs.buffalo.edu
Be warned: There is no PGP ability as of yet.

Let me emphisize that:  THERE IS NO PGP ABILITY ON THIS REMAILER. 

I have not gotten the pgp program up and running as of yet.  But... if
you want to bounce mail through the remailer... it shouldn't be to
much of a problem.  Just use one of the other remailer keys and
encrypt your message with that.  Just add the usual lines to your
message.  For example:

----Begin fake message to a remailer----
::
Request-Remailing-To: remailer@rebma.mn.org

--------BEGIN PGPv2.0 MESSAGE------ (endcoded with rebma's key)
blah blah
--------END PGPv2.0 MESSAGE-------

----End fake message to a remailer------


Report any problems to me or to any of the other remailing sites.

-- 
+==== Internet: babani@cs.buffalo.edu ===+======== Amateur-Radio: N2LYC ======+
!      Bitnet: V078LNGT@ubvms.BITNET     |        UUCP: rutgers!ub!babani     !
! Alternate: an173@cleveland.freenet.edu | Plsure dpnds on the othrs prmison. !
+When you finally discover all of lifes answers, they'll change the questions.+





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Fri, 4 Dec 92 17:46:33 PST
To: cypherpunks@toad.com
Subject: getting .hqx files with ftpmail
Message-ID: <9212050131.AB05869@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


A note for fools like me trying to get Mac .hqx files through "ftpmail"...

USE ASCII MODE!  Otherwise it defaults to adding an extra layer of "btoa"
encoding on the file (or you can switch it to uuencode, but why uuencode
an .hqx file--it's already plain text).  "btoa" files start like this:
        xbtoa begin
        wef9a87eg8a9wery8s7arg87gae8g7waeo87rwe8r(garbage)...
as opposed to uuencoded files like:
        begin fred.txt
        aewhgp9ergu90ser890syuer98gse98r(garbage)...
or .hqx files (this is from memory):
        (This file has to be decoded with BinHex 2.0)
        k9wegesz9p8rgy89serg9oser98ser98(garbage)...

I don't know where to find "btoa," and ftpmail's help message just says
to ask my local wizard.  He never heard of it.

--- Example request to ftpmail ---
        connect mac.archive.umich.edu
        cd mac/util/encryption
        ascii
        get macpgp2.0.sit.hqx

-fnerd
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Joe Thomas <jthomas@access.digex.com>
Date: Sat, 5 Dec 92 14:51:18 PST
To: cypherpunks <cypherpunks@toad.com>
Subject: Hardware RNGs
Message-ID: <Pine.3.05.9212051331.A28464-b100000@access.digex.com>
MIME-Version: 1.0
Content-Type: text/plain


I just joined the list (rather loudly, I'm afraid), but I've already seen
several writers complain about the quality of RNGs and PRNGs for the 
purposes of cryptography.  PGP stores up keystroke-derived random bits
in a file, which has been pointed out as a possible security hole.  But
requiring random keystrokes every time one wishes to send a message seems
an inconvenient tradeoff, to say the least.

Someone posted a plan for a Zener diode-based hard RNG on sci.crypt a few
weeks ago.  I'm not much of a solderer normally, but this seems like a 
good idea if anyone out there has tried it out and tested the output for
nonrandomness.  (Of course, ideally we'll have alpha-decay-based RNGs
--guaranteed random by the laws of physics-- but I'll settle for thermal
noise on the cheap for the moment).

Anyone tried these yet?  More to the point, does anyone have some code
patches for PGP to use a hard RNG preferentially over other random
bitstreams?  (Yeah, it would be pretty easy, but there's no sense in
duplicating effort if we could get something standardized, pretty and
portable agreed on.)

Joe

P.S. Sorry about the wasted bandwidth last week.  My fingers were moving
faster than my brain, but I should have recognized this address as a
probable mailing list.  Thanks to all who politely directed me to the
-request address.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Sat, 5 Dec 92 14:50:36 PST
To: cypherpunks@toad.com
Subject: test
Message-ID: <9212052203.AA19366@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain




This is a test of my new anon-remailer based on Hal's code.  It does not
yet feature pgp (pgp is having a hard time compiling on soda, but that
will change soon...)

To use it, just use the Anon-To: field in the header and mail
to hh@soda.berkeley.edu

There will soon be an even fancier remailer at soda (and not running out
of my account).  Details as they become available.

sincerely,
nobody





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Sat, 5 Dec 92 17:25:29 PST
To: cypherpunks@toad.com
Subject: Anonymous address problems
Message-ID: <9212060122.AA19491@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


We've had some discussion of anonymous addressing, which allows
someone to post an address at which mail can be sent to them without
people being able to find out exactly who they are.

I showed how the current remailers could, somewhat clumsily, allow
anonymous addresses.  The problem is, with a single-remailer anonymous
address that remailer sees whom each anonymous address corresponds to,
so you have to trust it.  Now that other encrypting remailers are up
it's possible to have anonymous addresses which go through more than
one remailer before going to the final destination.  This, I thought,
would provide a more secure address since a whole group of remailers
would have to be "broken" in order for someone to find out where a
given anonymous address leads.

However, with the current implementation, there is a security
weakness.  Whomever owns the last remailer in the chain for your
anonymous address can find out who you are.  They do this simply by
sending an anonymous message with known contents, like "test number
1598293".  They then watch all messages going through their remailer,
looking for one whose contents match what they sent.  If they are the
last remailer in the chain, when they see this message go through
them, they can look at whom it is being sent to, and so they then know
your true name.  So, a multi-remailer anonymous address is really no
more secure than a single-remailer one.

Chaum, in his "mix" paper, avoided this problem by having the
anonymous addresses include a random number which each remailer sees
as it decrypts the incoming message.  (There is always such a number,
it turns out, for the RSA encryption to be secure.)  He had the mix,
as it passes the message through, encrypt the contents with a
single-key algorithm (like DES) using this random number as the key.
This way the message is transformed at each step and so if it later
comes back through the same mix, it won't be recognizeable as the one
it sent earlier.  So the attack above fails.

For this to work, the user has to save the random numbers that were
used to construct his anonymous address, and decrypt the message using
DES with these as keys before going on to read it or public-key decrypt
it as usual.  This would be quite a bit less convenient.

Chaum goes on to say that these return addresses can only be used
once.  I was a little puzzled by the exact attack that he is trying to
defend against in applying this rule.  Chaum doesn't always make the
attacks clear, leaving that as an exercise for the reader.  I believe
the problem is that, say, the last remailer in the chain could send 100
messages to a given anonymous address (all would have different
contents).  Then, after working its way through the remailer chain, it
would see 100 messages going to the same final destination.  It could
guess that those 100 were the 100 it sent, especially if it repeats this
test every few days with different numbers.

Chaum's rule of allowing each anonymous address to be used only once
makes them much less useful.

These complications just go to show that real security doesn't come
easy or cheap.  There is still work to be done before we achieve the
goal of crypto anonymity.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Sat, 5 Dec 92 19:21:20 PST
To: cypherpunks@toad.com
Subject: remailers
Message-ID: <9212060320.AA03303@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Remailers are proliferating!  Several more will be coming on line soon!

Two thoughts:

Remailers should keep a directory of other remailers, along with their
keys.  They should, at random intervals, send messages to other remailers,
selected at random.  They should have a field like

Purpose:  traffic-analysis

If a remailer on this "ring" sees this field, it will have, say, a 90%
chance of remailing to another remailer in the ring, again, encrypted and
with the traffic-analsysis field.

This will cause a certain amount of random traffic between remailers.  A
traffic-analysis message could bounce around many times before finally
ending up in the great /dev/null.

We need two other things:  overseas remailers (for those of us who live
under US law).  Domestic (US) remailers could have their archives searched
with a searchwarant.  However, if your mail has gone accross the oceans a
few times, it would be pretty much impossible to get the neccessary warrants
and cooperation in all the countries its been through.

I'll set up a European remailer if someone else will.

The other thing we need to do is make a list of remailers and their keys and
put it up for ftp on soda.berkeley.edu in ~ftp/pub/cypherpunks.  In fact,
there could be an automatic service, whereby remailers automatically send
mail to a remailer at soda, listed their keys and protocols, and the soda
remailer automatically updates a remailer directory.

e





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: habs@acf3.NYU.EDU (Harry A. B. Shapiro)
Date: Sat, 5 Dec 92 19:27:02 PST
To: cypherpunks@toad.com
Subject: subscribe me
Message-ID: <9212060326.AA04183@acf3.NYU.EDU>
MIME-Version: 1.0
Content-Type: text/plain


subscribe me

-- 
habs@acf3.NYU.EDU
habs@gnu.ai.mit.edu
habs@well.sf.ca.us
habs@panix.com



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Sun, 6 Dec 92 10:30:31 PST
To: cypherpunks@toad.com
Subject: this is a test
Message-ID: <9212061829.AA03378@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



igonore this message...

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Sun, 6 Dec 92 12:44:52 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9212062044.AA06744@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks!

Like several people (I guess), I am working on an implementation of
digital cash.  Because of the possible legal repurcussions, I'd prefer
to remain anonymous at this time.  Thanks to the efforts of the people
on this list, this is now possible.

My implementation is pretty far along.  It uses PGP modules for the
arithmetic, so the speed is good.  It works on Unix and I should be
able to get it working on MSDOS in a day or two.  Sorry, I don't have
the ability to work on a Mac version.

Here are some of the features.  The basic cash algorithm is the Chaum
system which was posted here.  Multiple denominations are supported,
using different exponents for each denomination.  The program is
presented in the context of a package to be used for an email based
game like Monopoly where the program would be used to allow cash
transfers.  One player is the "banker", and he uses a different
execution module than the other players.  The banker program keeps a
database of used note numbers which is used to detect money reuse.
The database is maintained using a freeware version of the "dbm"
package, so it should be fast even for large note number databases.

The mapping between exponents and values is as follows:

    exponent	    value
	17		1
	19		2
	23		5
	29		10
	31		20
	37		50
	41		100
	43		200
	47		500
	53		1000
	59		2000
	61		5000
	67		10000

and so on, up to a value of 2e9.  The exponents are ascending primes
starting with 17.  This was chosen because you want them to be
smallish for fast note checking, but it was too slow to find primes p
and q for the bank key such that (p-1)(q-1) was not divisible by any
small primes.  The program chooses random p and then tests p-1 to make
sure it passes the divisibility test, and rejects it if not.  Too many
were being rejected when I started with an exponent of 3.  Starting
with 17 rejects about 1/2 the exponents, compared to something like
80% when I started with 3.  The "value" fields are presumed to be
cents, but could be whatever you like.

The code I've written does not do anything other than the basic
electronic cash algorithms.  It does not do bank account maintenance.
It doesn't do PGP encryption.  It doesn't send mail.  (It does have
some functions to scan and check the files created by the program.)

Cash generation is a 3 step process.  First, the user creates what I
call a "withdrawal request" packet.  This is a set of triplets of the
form (e, s, refx), where e is the exponent from the table above, s is
a 16-byte "unique identifier" used solely to link these withdrawal
requests with the returned messages from the bank, and refx is r^e * f(x).
f(x) is MD5 of x, padded to the size of the bank's modulus n using the
PGP routine which pads MD5 signatures.  This padding helps make sure the
arithmetic is more "mixing".  x is the random input to MD5, which I've
chosen as 64 bytes since that is the block size MD5 works on.  (The
output of MD5 is 16 bytes.)  r is the blinding factor.  This is now
128 bits long; longer r's take too long to calculate r^-1 in the third
step, below.  (It takes longer for PGP to calculate r^-1 than to do an
RSA decryption, for r = n = 1024 bits!)

Second, the bank program converts the withdrawal request packet into
what I call a "withdrawal" packet, by just RSA-decrypting the third
entry using the inverse exponent "d" for the value exponent "e".
(These "d" values are calculated at keygen time and stored with the
bank's key information in a private file.)  I call the return triplet
(e, s, rfxd), where e is the value exponent again, s is the same
unique identifier, and rfxd is r * f(x)^d.

(As I said above, the code I've written does not try to maintain
account balances or do any other banking functions.  It just does the
cash algorithms.  There is a routine to scan a withdrawal request and
return the total value being requested for withdrawal.  The idea was
that this could be used as input to a banking program to decide
whether to allow the withdrawal.)

Third, the "player" (e.g. user) program transforms the withdrawal
packet into a "money" packet, by un-blinding it.  To do this, it has
to recover the x and r which correspond with each triplet.  This is
done by the use of a dbm database of "pending withdrawal requests"
which is written during step 1, above.  The database entries are keyed
by (e, s) and return the corresponding (x, r) which were generated
during step 1.  Using x and r, the user transforms (e, s, rfxd) into
(e, x, fxd), the digital cash.  e is the value exponent, x is the
random 64-byte number, and fxd is f(x)^d, the signed version of the
MD5'd and padded x.

There are also player functions to scan and check a money file
(comparing a calculated f(x) to fxd^e), merge money files, and extract
some items from a money file into another money file (this last is
what is to be used for payment).  There are banker functions to check
incoming money and compare against the used-note database, and to add
incoming money to that database.  (The database consists of the
16-byte f(x) values for each note.)

I am pretty happy with the basic routines, but the user interface
needs work.  There are three kinds of files floating around
(withdrawal requests, withdrawals, and money files) and I'm worried
that this will be confusing to the user.  If he accidentally deletes
one at the wrong time he could lose money permanently.  Or if he
accidentally reuses one he could be accused of fraud.  I'm not sure
what the best model is for the user.

The specific issues of creating withdrawal messages and extracting
"bills" from a money file are areas where the user interface should be
made nice.  We want to make it easy for the user to specify exactly
what denominations he wants to work with.  One possibility is to
simply have him input the amount (e.g. $10.55) and the program
calculates that that's a 1000, a 50, and a 5, but this isn't really
flexible enough.  A nice system would be to give him a list of options
and let him fill out a form on-screen, but that's hard to do portably.

Another idea I've had is that there should be a special money file
called the user's "wallet" which is the default place where incoming
money from the bank should go.  This might help organize things.  He
still needs to be able to create other money files for paying other
people, and remembering to delete them after he sends them.

Any suggestions or thoughts on these interface issues, or comments
about how this program could or should be integrated into a larger
system, would be appreciated.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/
sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE
a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR
tAl4UGhhZWRydXM=
=HVRq
-----END PGP PUBLIC KEY BLOCK-----






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@ocf.Berkeley.EDU
Date: Mon, 7 Dec 92 00:30:49 PST
To: cypherpunks@toad.com
Subject: yet another remailer
Message-ID: <199212070730.AA07386@plague.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



I've set up another remailer, this one on my ocf account.  It's also based
on Hal's (very easy to use and useful) script and does not yet have
encryption because pgp201 is not the most portable thing around.

To use, just do the standard thing:

send mail to hh@ocf.berkeley.edu with the line:

Anon-To:

or

Request-Remailing-To:

and it will do the rest.  Have fun!

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Mon, 7 Dec 92 09:56:00 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9211077237.AA72375@jplpost.jpl.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain


          ruthere




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Chris Hibbert <hibbert@xanadu.com>
Date: Mon, 7 Dec 92 19:55:23 PST
To: uunet!ghsvax!hal@uunet.UU.NET (Hal Finney)
Subject: Re: Anonymous address problems
In-Reply-To: <9212060122.AA19491@nano.noname>
Message-ID: <9212071859.AA11109@entropy.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain



There's a cheap fix for the particular problem you mentioned, Hal. 
(Of course, that's usually the case, and it's usually too weak a fix
to help generally, but I think this one gives us back the ability to
use anonymity here.)  

The cheap fix is to make sure that the last remailer in the chain
(the one closest to you) is your own!  That way you can ensure no
one else checks its translation.  No one else can be sure which is
the second-to-last hop, so they can't tell who owns the last
remailer. 

Chris




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Mon, 7 Dec 92 08:26:16 PST
To: cypherpunks@toad.com
Subject: CHATTER Re: Broadcast/Filter vs. "Fetching"
Message-ID: <9212071546.AB14663@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


(I put "CHATTER" in the subject line as a clue that this is general talk
off the subject of directly implementing crypto stuff.)

Yanek Martinson    <yanek@novavax.nova.edu> sent an interesting message
to me--I think he meant to post it--in response to my gripe:

>> (I mean, while I'm at it, I hate the broadcast-and-filter model of netnews,
>> CD ROMs, and cable TV.  I want things available for me to go fetch.)
>
>But if you have the disk space and bandwidth to spare, it really does
>make sense to receive everything and then decide what you want.

Perhaps our company could make room for a couple days worth of the complete
netnews.  But,
  o  That's hardly all the information there is.
  o  I could never read it all, and I don't trust computer filters much.
  o  I don't want to be a slave to the newsfeed/use-it-or-lose-it deal;
     I want to follow threads into the past, at my leisure.  I want to let
     some discussions cook and then come back to them.

>In your "fetch" scenario, what if I don't like (strongly) what Joe wrote.
>So I can nuke Joe (or his archive) and no-one can "Fetch" the article.

This is what I found interesting.  You would really like the network (some
network) to support distributed redundant archives, preferably with cross-
checking.  It would be even nicer if information could be stored, with
storage cost charged to the owner and/or readers, and yet not have it 
knowable where the information was.  Somehow a backwards mix setup.  Put 
on your crypto thinking caps, kids.

>On the other hand with the current set-up, it has already propagated 
>to hundreds of thousands of sites and it's impossible to stop.

Yes.  But, say, tens of untraceable sites would be okay.  The flip side of
100K x redundancy is the little emily postnews handslap--"ARE YOU SURE?"--
and the rigamarole over creating new groups, and whether all the machines
between you and the center of the universe get all the groups, etc.
Plus the fact that most sites delete the stuff after a week or two, and
all the effects on people's writing that has.

>Also, if you want to filter stuff, then you should pay for the CPU
>that does the filtering for you.

My brain filters my mail!  Boy do I pay for it!

>Why would you expect someone else
>to run your filter on their machine just so you would know if you
>wanted to fetch their article.

??  I don't want machine filtering at all.  Mostly I want references I can
follow up easily.  That's what fetching means.

>Maybe I did not understand what you meant by "fetching".  

Hope it's clearer.

>Could you describe your idea in more detail?
>I absolutely agree that most of what comes in over my
>newsfeed is junk, I just don't see a good way of 
>fixing this problem while retaining the robustness
>and widespread communications capability.
>
>> -fnerd
>> quote me...within *reason* of course
>
>(I guess 4 lines (including the sig) is well within reason)

-fnerd
quote me
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@alumni.cco.caltech.edu
Date: Mon, 7 Dec 92 19:52:58 PST
To: cypherpunks@toad.com
Subject: pgp2.1 released
Message-ID: <9212072305.AA21821@alumni.cco.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain


PGP 2.1 is released.  It's on soda.berkeley.edu, for your convenience,
in directory pub/cypherpunks.

The 2.1 release has the ability to sign a message as leave the message
in plaintext.  This should be used by all the pseudonyms in the group
to prove continuity of authorship.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Mon, 7 Dec 92 19:51:58 PST
To: cypherpunks@toad.com
Subject: ocf remailer
Message-ID: <9212080024.AA22987@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



For various reasons, my remailer on the ocf is going down indefinitely.  It
was fun while it lasted, I laughed, I cried, but now it's over.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Mon, 7 Dec 92 19:51:29 PST
To: cypherpunks@toad.com
Subject: Anonymous address problems, etc.
Message-ID: <9212080059.AA20745@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Chris Hibbert sent me a solution for the problem I mentioned about the
last remailer in an anonymous address chain being able to discover the
true name for the address.  He suggested making your own remailer be
the last one in the chain.  If you added a little padding, so the
second-to-last remailer couldn't tell (from the small size of the
encrypted address) that yours was last, this sounds pretty good.  And
it's another reason to run a remailer, even if you had to do it
manually.

On the digital cash issue - I think we should get some kind of
implementation of digicash (oops, "electronic money") out for people
on the list to play with.  Then, we should think of some kind of
experimental email-based game to play which would use the special
characteristics of anonymous cash.  Maybe we could use the remailers,
too.  Players would send cash back and forth to each other as part of
the game.  Even if the tools are sort of rough at first, this could
show where the most work is needed.

Can anyone think of a good kind of game that we could play?  As Eric
Hughes pointed out, the cash doesn't have to be "cash", it could
represent "gold" or "carrots" or any other material which exists in
limited quantity.

I think it was on the extropians list that Eli Brandt pointed out the
need for a shorter term than "digital cash" for this cryptographic
money.  He suggested "cryps".  I thought of "emoney" or "ecash" by
analogy to "email".  Here's another one: "crydets", based on
"credits".  Or maybe we should call them "Chaums".  That way he'd be
less likely to sue us for infringing on his patent. ;-)  I notice he
managed to cleverly name DC-nets after his initials so maybe he'd like
this.

Hal
74076.1041@compuserve.com

P.S. I hear PGP 2.1 is coming out today.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@pmantis.berkeley.edu
Date: Mon, 7 Dec 92 19:56:34 PST
To: cypherpunks@toad.com
Subject: another remailer!
Message-ID: <9212080357.AA10697@pmantis.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


I set up another remailer.  All in all it took me about 30 min to compile
perl and set up Hal's script.  It's too easy!

Just do the standard thing:  mail to hh@pmantis.berkeley.edu with the line
in the header Anon-To: or Request-Remailing-To:

Have fun!

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@cicada.berkeley.edu
Date: Mon, 7 Dec 92 21:45:33 PST
To: cypherpunks@toad.com
Subject: another remailer (again?)
Message-ID: <9212080541.AA11090@cicada.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Yes, it's the second remailer I've set up today.  Gee, at this rate, I'll
have the entire CPU power of the United States dedicated to remailing
within four months.

Just do the usual thing:

mail hh@cicada.berkeley.edu with the header line Anon-To: or
Request-Remailing-To: and the remailer does the rest.  cicada and pmantis
have been able to compile pgp201 and so they will soon have encrypted
remailer capability.  They will also soon be running pgp21 (as soon as I get
a chance to compile that).  They are very fast machines, so I will probably
give them military grade keys.  They are also very secure machines.

It's too bad about not being able to use the ocf, but those machines are
slow anyway and probably wouldn't be able to run pgp ever.  My soda remailer
should be running pgp fairly soon.  And I have 1-3 remailing sites almost
ready to go, probably coming on sometime next week.  And hughes is working
on another remailer at soda, a really fancy one.

Have fun everyone!

e





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eli Brandt <ebrandt@jarthur.Claremont.EDU>
Date: Mon, 7 Dec 92 22:12:22 PST
To: cypherpunks@toad.com
Subject: Re: Anonymous address problems, etc.
In-Reply-To: <9212080059.AA20745@nano.noname>
Message-ID: <9212080612.AA05211@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> money.  He suggested "cryps".  I thought of "emoney" or "ecash" by
> analogy to "email".  Here's another one: "crydets", based on
> "credits".  Or maybe we should call them "Chaums".

I passed over "emoney" et al, because I thought they just sounded
lousy.  Too brute-force... "crydets" I like, though.  BTW, it was
"cryp", like "scrip".  Any further suggestions before the RFD?  :-)

Does anyone have a current contact for Chaum, or maybe know the
fellow, in order to ask him how, well, PKP he's going to be about
the whole thing?

> Hal

	 PGP 2 key by finger or e-mail
   Eli   ebrandt@jarthur.claremont.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Mon, 7 Dec 92 22:25:37 PST
To: cypherpunks@toad.com
Subject: remailers, the prime user of bandwidth in the US (well, not yet)
Message-ID: <9212080624.AA17822@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Could all remailer operators please mail me (hh@soda.berkeley.edu) the
following information so that I can set up a remailer directory?  There are
so many remailers right now that this needs to be done:

1) address to mail to. for instance, hh@soda.berkeley.edu

2) how it works. what lines to put in the header, how to give it a pgp
block, etc.

3) pgp key (if used)

4) how to contact the owner. this may be anonymous. you can easily set up
your mail delivery file to have a Purpose: field and check it for
"contact-owner" which would then forward the mail to the owner.

4) owner's name and email address (optional).

I will compile all of this information and put it up for ftp on soda.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Derek Atkins <warlord@MIT.EDU>
Date: Mon, 7 Dec 92 19:49:44 PST
To: cypherpunks@toad.com
Subject: Just in case you haven't heard (PGP 2.1 released)
Message-ID: <9212080347.AA10257@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

PGP 2.1 Available
- -----------------

Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. 
This new version of the world's most popular and politically
controversial public key encryption program has numerous bug fixes
over version 2.0, and several new features.  

For example, you can now display the MD5 hash of a public key, to
facilitate verifying it over the telephone with the owner of that
public key.  Also, it is now possible to send via email an
unencrypted signed message without putting the whole message in
Radix-64 format, to make it possible to read without PGP.  This is
analogous to the PEM MIC-CLEAR signed message functionality.

PGP 2.1 incorporates many patches from the user community to port it
to more platforms.  And it runs faster.  Also, a lot of annoying bugs
and ergonomic oversights have been fixed.  PGP 2.0 fans will find
many rough edges have been smoothed out.

The filenames are pgp21.zip for the MSDOS executable release, and
pgp21src.zip for the source code release.  You must have PKUNZIP
version 1.1 or later to unzip them, or they won't unzip.  The primary
initial FTP sites that have it are:

Finland:    nic.funet.fi  (128.214.6.100)
            Directory: /pub/unix/security/crypt/

Italy:      ghost.dsi.unimi.it  (149.132.2.1)
            Directory: /pub/security/

As previously, this prohibited and politically popular program will
probably propagate through the same channels as PGP 2.0.  Of course,
if you live in the USA, you really shouldn't be using it.

If you have any questions about where else to get it, contact Hugh
Miller, at hmiller@lucpul.it.luc.edu.  Hugh can send you the latest
evolving list of FTP sites, BBS phone numbers, and other sources.

Philip Zimmermann
Phil's Pretty Good Software


-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyLbAuJ13g7/Z/cLAQFxoAP+OqIqZu2zfA7LycuBJmaF0cms6xyYYok+
ifFW5hIKYUDqvVwLQg5kSXRIUY9fbSXaox6bnww+2YCoEacbzMAAVgTiw8TU7QG0
JryTOHsUIihq9JNBOQ5ONfmHzH0w2gaQ5SGEcJK93typoyvNQMtdtVSeIfkl6ImJ
vs/OHzY5LiU=
=nV70
-----END PGP SIGNATURE-----




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Tue, 8 Dec 92 02:48:26 PST
To: ebrandt@jarthur.Claremont.EDU
Subject: Re: Anonymous address problems, etc.
Message-ID: <199212081046.AA21621@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain



How about e-marks...?  Sort of the next big thing after D-marks (Deutche
Marks, you know, German currency).  I don's like "crydets" because it seems
like it's not straightforward pronounciation, especially when dealing with
other languages; too easy to confuse with "credits," and "cry-debts"
("boo-hoo-hoo, another collection notice!")... we need a word which is
less ambiguous than that.  "Cryp" like "scrip" is also like "Crip," which is
a very very unpleasant connotation and might leave a bad taste in the mouth
of Latinos in the US.  

E-Marks.  Clear and straightforward, easy to pronounce and not too many
syllables or weird spelling tweax.  

-gg.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu (John Gilmore)
Date: Tue, 8 Dec 92 05:31:54 PST
To: fnerd@smds.com (FutureNerd Steve Witham)
Subject: Captain Midnight returns?
In-Reply-To: <9212032155.AB19933@smds.com>
Message-ID: <9212081331.AA15358@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> ...put it on your crypto feature ring.  Has a sort of futuristic ring to it.

Hmm, perhaps we should eventually build real Captain Midnight Decoder
Rings, which would fit around your finger.  When the face of the ring
was inserted into a DIN-plug serial port, it would power up, and talk a
serial protocol to do the crypto operations needed to sign and decrypt
messages, a la Phil Karn's design.  There are smart-card microcontrollers
with most or all of the right features -- we'd just have to figure out how
to pot one into a ring with a truncated DIN-plug.

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Tue, 8 Dec 92 09:53:58 PST
To: cypherpunks@toad.com
Subject: peasant_multiply question
Message-ID: <9212081715.AA26885@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


Folks--

I got out my copy of the original RSA paper, and I'm comparing it to the
PGP 2.0 code.  I have a question about the peasant_modmult routine (the
simplest modmult in PGP).  Here's pseudocode of what I think it's doing:

    /* Inputs: modulus, multiplier, multiplicand */
    /* Output: prod */

    prod = 0;
    set sniffer to most significant bit of multiplier;
    nbits = number of significant bits in multiplier;

    while( nbits-- )
        {
        shift prod left 1;
        prod = prod - modulus;
        if( the bit of the multiplier being sniffed = 1 )
            {
            prod = prod + multiplicand;
            prod = prod - modulus;
            }
        move the sniffer to the next bit of the multiplier;
        }

My question is (assuming I'm understanding the code right), how can it
work subtracting modulus unconditionally all the time?  Won't it make
prod negative sometimes, and then keep multiplying the negative number
by two until it overflows?   Isn't that a problem??

-fnerd
quote me
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Tue, 8 Dec 92 14:53:49 PST
To: cypherpunks@toad.com
Subject: PGP key generation
Message-ID: <9212082250.AA22082@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Steve Witham asks about PGP's "peasant_modmult" routine, how it can
subtract the modulus on each addition.  It doesn't, but the code is a
little misleading (taken from mpilib.c, PGP 2.1):

    while (bits--)
    {	mp_shift_left(prod);
	msub(prod,pmodulus);	/* turns mult into modmult */
	if (sniff_bit(multiplier,bitmask))
	{   mp_add(prod,multiplicand);
	    msub(prod,pmodulus);	/* turns mult into modmult */
	}
	bump_bitsniffer(multiplier,bitmask);
    }

What is confusing is that "msub" looks like "mp_sub".  Actually, msub
is a macro defined in mpilib.h:

#define msub(r,m) if (mp_compare(r,m) >= 0) mp_sub(r,m)
	/* Prevents r from getting bigger than modulus m */

So, msub actually only subtracts if it's necessary, as would be
expected.


Jim McGrath asks:

> When PGP generates keys doesn't it always pick d and e to have
> the same number of bits, ie 446 for the strongest type?

d and e are the decryption and encryption exponents.  e is chosen to
be small, typically the number 17 or slightly larger.  d is then about
the size of n, your key modulus.

p and q, the two primes which are multiplied to get n, are about the
same size, usually.  PGP does have some code to make sure they aren't
too close to the same size (taken from rsagen.c, PGP 2.1):

        /*	See if p and q are far enough apart.  Is q-p big enough? */
        mp_move(u,q);	/* use u as scratchpad */
        mp_sub(u,p);	/* compute q-p */
        if (mp_tstminus(u))	/* p is bigger */
        {    mp_neg(u);
            too_close_together = (countbits(u) < (countbits(p)-7));
        }
        else		/* q is bigger */
            too_close_together = (countbits(u) < (countbits(q)-7));

        /* Keep trying q's until we get one far enough from p... */
    } while (too_close_together);

What this does is make sure that |p-q| is > 1/128 of the larger of p
or q.  This is designed to make sure that p and q are both very far
from the square root of n.  I.e. if n were 1024 bits, p and q could
both be about 512 bits, but they would be at least about 2^505 from
the square root of n, foiling the square root attacks.

Hal
74076.1041@compuserve.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Tue, 8 Dec 92 11:38:37 PST
To: cypherpunks@toad.com
Subject: Re: PGP questions
Message-ID: <9212081910.AB28737@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


>It's probably good to discuss how PGP works here, for educational
>purposes, but I would expect people to get the source code if they
>really are interested.  I can give some pointers here to answers to
>some of the questions people have asked.

Thanks for the answers, Hal.  I have been digging into the original
RSA paper and the PGP 2.0 sources.  By the way, sorry if my response
time is long; I've been traveling for work lately.

I suggested leaving the minimum set of compute-intensive routines
in C and implementing the higher-level stuff in some higher-level language 
("HLL"), possibly interpreted.  Hal pointed out some of the crunching 
jobs other than modmult.  Using an HLL has cons as well as pros to it.

The main advantage (for my purpose here) is that C code has a lot of noise 
that gets in the way of understanding.  This could also be improved by some 
coding style changes--for instance, using some object-oriented stuff (data 
structures that handle more of their own details) and, ahem, fewer #ifdefs...
Another advantage of an HLL is ease of trying out different, er, schemes.

If I used an HLL, I think it would be one that had very C-like syntax.

The main drawback of an HLL is that it's another program that you
have to trust.  Sometimes inner parts of interpreters and compilers are 
hard to write so that they are correct *and seem* correct when you look 
at them.  A couple of things they can do are automatic space allocation, 
garbage collection and "burning" data that's no longer in use ("garbage 
burning?").

-fnerd
quote me
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Alan Hunter <a.hunter@dunaad.co.uk>
Date: Tue, 8 Dec 92 14:56:40 PST
To: cypherpunks@toad.com
Subject: Re Anonymous address problems etc
Message-ID: <2b25279b.dunaad@dunaad.co.uk>
MIME-Version: 1.0
Content-Type: text/plain





On Mon, 7 Dec 92 16:59:12 PST, (Hal Finney) ghsvax!hal@uunet.uu.net wrote:
>
> On the digital cash issue - I think we should get some kind of
> implementation of digicash (oops, "electronic money") out for people
> on the list to play with.  Then, we should think of some kind of
> experimental email-based game to play which would use the special
> characteristics of anonymous cash.  Maybe we could use the remailers,
> too.  Players would send cash back and forth to each other as part of
> the game.  Even if the tools are sort of rough at first, this could
> show where the most work is needed.
> 
> Can anyone think of a good kind of game that we could play? 

How about making cypherpunks a subscription mailing list, and paying
contributors?

Alan




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "McGrath, James" <MCGRATHJ%GRNET@lan.lincoln.cri.nz>
Date: Tue, 8 Dec 92 13:47:01 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9212082145.AA14652@crop.lincoln.cri.nz>
MIME-Version: 1.0
Content-Type: text/plain


Karl said: 

> Also, p and q should differ in length by a few digits otherwise
> an enemy may begin to try factoring n by starting near sqrt(n).

When PGP generates keys doesn't it always pick d and e to have
the same number of bits, ie 446 for the strongest type?

Is this the same thing? 

I suppose that if you are allowed leading 0s it isn't a problem
at all, but if the first couple of bits were ones in each key, (a
16:1 chance) wouldn't that significantly reduce the power
required to factor the PK using this approach?

Just a thought,

Jim




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Alan Hunter <a.hunter@dunaad.co.uk>
Date: Wed, 9 Dec 92 12:58:03 PST
To: cypherpunks@toad.com
Subject: Experiments in Digital cash
Message-ID: <2b264d98.dunaad@dunaad.co.uk>
MIME-Version: 1.0
Content-Type: text/plain




On Wed, 9 Dec 92 02:25:49 -0800, "John Draper" <crunch@netcom.com> wrote:
> Cm'on Alan,  give us unemployed folks a break.   Life's a bitch already
> for us unemployed folks.    To have to pay to get Cypherpunks mail
> would not go very good.

Just in case...

I meant as an experiment in the use of digital cash and banks.  I'm
sure that DigiBank Inc would give us all an overdraft facility for
starters.

Alan




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu (John Gilmore)
Date: Thu, 10 Dec 92 03:03:08 PST
To: cypherpunks@toad.com
Subject: No more PGP keys without signatures, please!
In-Reply-To: <9212080624.AA17822@soda.berkeley.edu>
Message-ID: <9212101103.AA02644@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


People continue to post PGP keys that are not vouched for by anyone.
E.g. none of the keys for remailers has any signatures.  This makes it
impossible to trust those remailers, since anyone could have generated
such a key and sent it through a remailer saying it was from someone
else.

If you put up a remailer service, sign its key with your personal key,
at least.  Preferably get a few other people to sign it (by showing them
that they key is really the one used in the remailer, in person).

If you generate a key for yourself, don't just post it -- take it to
a friend, and cross-sign each others' keys.  If you do that a few times,
then you can post it, and the receipients are likely to know one of those
friends, possibly trusting them to certify your key.

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Edward Vielmetti <emv@msen.com>
Date: Thu, 10 Dec 92 05:01:55 PST
To: jih@ox.com
Subject: 'token exchange' market in Arizona
Message-ID: <m0mznTp-0000A8C@garnet.msen.com>
MIME-Version: 1.0
Content-Type: text/plain


For you all.  Interesting because it would appear to be a real live
marketplace, with real live money, tho no crypto per se in there.

--Ed

------- Forwarded Message

From: rkeca04@uts.manchester-computing-centre.ac.uk (Thomas Krichel)
Subject: Arizona token exchange
To: cti-econ@mailbase.ac.uk
Date: Thu, 10 Dec 92 11:55:03 GMT

  Greetings,

  this is an  item from corryfee. Apologies to those who have
  already seen it. I thought it was sufficiently interesting
  to pass it on. 

  BTW, the some of the results of the Santa Fe experiment, to which
  the text refers, will be published in a forthcomming book by 
  John Rust and Dan Friedman "Double Auction Markets: Theory, Institutions,
  Evidence". Publisher is Addison-Wesley (Santa Fe Institute series
  On Studies in the Science of Complexity).

  Cheers,

  ______                               
    /   /                              Department of Economics
   /   /_  ________  __.  _            University of Keele
  /   / /_(_) / / <_(_/|_/_)           ST5 5BG                         
    _   ,                  _           Great Britain          
   ' ) /           /      //           Tel.: 44 - 782 - 714847  
    /-<  __  o _. /_  _  //            Fax:  44 - 782 - 717577
  ./   )/ (_<_(__/ /_</_</_            E-mail: Krichel@uts.mcc.ac.uk

> 
>  
>  
>  
>                             ANNOUNCING THE OPENING OF THE
>  
>                             ARIZONA TOKEN EXCHANGE (AZTE)
>  
>                                   January 1, 1993
>  
> Earn cash profits by competing against computerized program traders
>  
> THE CHALLENGE
>  
> Is "artificial intelligence" superior to human intelligence? In
> some domains such as chess, computer programs now outperform all
> but the very best human players.  However in other domains such as
> speech, handwriting, and other kinds of pattern recognition,
> computers lag far behind human beings.  On Wall Street computer
> "program traders" are becoming increasingly common, yet there is
> substantial controversy over their performance -- they have even
> been blamed as a factor in the October 1987 stock market crash.
> The purpose of this study, co-sponsored by the University of
> Arizona's Economic Science Laboratory and the Santa Fe Institute,
> is to compare the performance of human and program traders to see
> whether humans can learn to exploit the limitations  and
> idiosyncracies of computers in repeated interactions.
>  
> THE ARIZONA TOKEN EXCHANGE
>  
> To compare the performance of human and program traders we have
> created a computerized market, the Arizona Token Exchange (AZTE),
> in which a fictional commodity, "tokens", are traded.  The market
> is a simplified version of commodity exchanges such as the Chicago
> Board of Trade where buyers and sellers are able to call out bids
> and asks to buy or sell units of the commodity.  In each trading
> session on AZTE traders are assigned the role of buyer or seller
> and are given an allocation of tokens.  A seller's objective is to
> sell their tokens for as much as possible above the token cost and
> a buyer's objective is to buy tokens as cheaply as possible below
> their redemption value.
>  
> By ranking the token costs and redemption values, well-defined
> supply and demand curves can be constructed.  The intersection of
> these curves defines the so-called competitive equilibrium (CE)
> price and quantity, at which neoclassical economic theory predicts
> all trading will occur.   The complication is that in the AZTE,
> each trader's token costs and redemption values are private
> information and differ from trader to trader.  Thus traders in the
> AZTE face a complex sequential decision problem: how much should
> they bid or ask for their own tokens, how soon should they place a
> bid or ask, and under what circumstances should they accept an
> outstanding bid or ask of some other trader? An additional
> complication is that each trading session runs for a fixed amount
> of time.  This creates a difficult trade-off, for if traders spend
> too much time looking for a good deal, they may find themselves
> locked out of the market without trading anything.
>  
> HOW IS TRADER PERFORMANCE EVALUATED?
>  
> In the AZTE there is a well-defined performance measure: trading
> efficiency, EFF.  This is the ratio of profits a trader actually
> earns divided by the profits it would have made if all trades took
> place at the competitive equilibrium level.  Thus, if a trader's
> EFF is greater than 100% they are earning more than their "fair"
> share of the profits.  The use of EFF is more desirable
> performance measure than simply using trading profits, since
> profits depend on the token allocations which are allocated at
> random from a known distribution.
>  
> After each trading session, participants will earn cash profits
> equal to the following linear function of their efficiency:
>  
>      $ payments =  a + b(EFF-100)
>  
> The term a represents a fixed fee paid for participating in the
> trading session and the term b(EFF-100) represents a bonus
> (penalty) for trading above (or below) 100% efficiency.  Thus, it
> is possible to lose money in any particular trading session.
> Dollar earnings are cumulated over successive trading sessions and
> subjects are eligible to "cash out" at any time after participating
> in a minimum number of trading sessions (provided cumulative
> earnings are positive).
>  
> THE OPPONENTS: COMPUTER PROGRAM TRADERS
>  
> Unlike real commodities markets where most traders are humans, in
> the AZTE all of your opponents will be computer programs.  The
> opponent programs will be selected from a field of over 30
> different trading strategies including winners of the Santa Fe
> Institute's Double Auction Tournament held in March, 1990.  The
> program traders range in sophistication from simple rules of thumb
> (such as Gode-Sunder "Zero-Intelligence" strategy) to sophisticated
> optimizing/learning algorithms (such as neural nets and genetic
> algorithms) developed from the recent literature on artificial
> intelligence.  The identities of your opponents will (usually) be
> revealed to you at the start of each trading session.  You will
> also be informed about other market characteristics such as the
> number of buyers and sellers, the number of tokens, and the joint
> distribution from which token values are drawn.
>  
> SETTING UP AN ACCOUNT
>  
> To trade on the AZTE you will need a Unix or PC-compatible computer
> linked to the Internet computer network.  We provide the trading
> interface software that allows you to log on and trade at any time
> you like and for as long as you like (subject to general
> restrictions).  To qualify for an AZTE trading account you need to
> file an application providing information on your address, phone,
> and email address, and a release form stating whether or not you
> want to remain anonymous in published analyses of the outcome of
> this experiment.  Upon receipt of the application we will set up a
> trading account and access password.  Your dollar earnings will
> cumulate in your account until you decide to cash out, at which
> time we will close your account and mail you a check for the total
> amount of your earnings.
>  
> The software and ASCII traders' manual (including the application
> form) is available via anonymous ftp on "fido.econ.arizona.edu", in
> the azte sub-directory.  The manual (azte.man) explains how the
> software works and what is required to use it.  We suggest you ftp
> this first and read through it, then get the appropriate trading
> interface for your system.  The DOS interface requires VGA graphics
> resolution and the use of Clarkson packet drivers for the network
> interface card.  The Clarkson drivers are also available via ftp on
> "fido.econ.arizona.edu".
>  
> If you don't have access to anonymous ftp, we will mail you a
> diskette containing the software and trader's manual.  To cover the
> costs of a diskette and surface mail, send $5.00 to:
>  
>        Shawn LaMaster
>        Manager, Economic Science Systems Development
>        Economic Science Laboratory
>        McClelland Hall, Room #116
>        University of Arizona
>        Tucson, Arizona  85719
>        (602) 621-6218
>  
>        Internet: lamaster@ziggy.econ.arizona.edu
>  
> We will assist in ftp and setting up the Clarkson packet drivers,
> just give us a call.
>  
>  
> The AZTE software was co-developed by:
>  
> Sean Coates        Economic Science Laboratory, University of Arizona
> Shawn LaMaster     Economic Science Laboratory, University of Arizona
> Richard G. Palmer  Duke University
> John Rust          University of Wisconsin
> Vernon L. Smith    Economic Science Laboratory, University of
> Arizona
> 




------- End of Forwarded Message





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hughes (Eric Hughes)
Date: Thu, 10 Dec 92 08:01:27 PST
To: cypherpunks-announce@toad.com
Subject: No Subject
Message-ID: <9212101601.AA08764@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Fourth Meeting

When: Saturday, Dec 12, 1992, 12:00 noon
Where: Cygnus Support offices

Schedule: 
	Noon	Schmooze, key exchange
	1:00	Business
	5:00	Adjourn

Agenda:

1. Media coverage.  Do we want to deal with the	press?  If so, how?

2. Reputation Systems.  Dean Tribble presenting.

3. Authenticated Diffie-Hellman (STS). Arthur Abraham presenting.

4. Reports


Notes:

1. Please be prompt.  We will begin the business section at 1:00
sharp.

2. Bring a portable computer and your key rings for PGP key exchange
and signing.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: andrew_derry@sfu.ca
Date: Thu, 10 Dec 92 09:31:17 PST
To: cypherpunks@toad.com
Subject: Key swap in Vancouver, BC, Canada, anyone?
Message-ID: <9212101730.AA00143@whistler.sfu.ca>
MIME-Version: 1.0
Content-Type: text/plain


Is anybody in, or comming to, Vancouver, BC that I could swap public keys
with?

Thanks.
---
Andrew Derry                      |
ACS@HCC - Simon Fraser University |
Internet: derry@sfu.ca            |





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hughes (Eric Hughes)
Date: Thu, 10 Dec 92 11:14:03 PST
To: cypherpunks-announce@toad.com
Subject: Directions to Cygnus support offices
Message-ID: <9212101913.AA13306@toad.com>
MIME-Version: 1.0
Content-Type: text/plain



	Cygnus Support
	1937 Landings Drive
	Mt. View, CA  94043
	+1 415 903 1400   switchboard
	+1 415 903 1418   John Gilmore

Take US 101 toward Mt. View.  From San Francisco, it's about a
40-minute drive.  Get off at the Rengstorff Ave/Amphitheatre Parkway
exit.  If you were heading south on 101, you curve around to the
right, cross over the freeway, and get to a stoplight.  If you were
heading north on 101, you just come right off the exit to the
stoplight.  The light is the intersection of Amphitheatre and
Charleston Rd.  Take a right on Charleston; there's a right-turn-only
lane.

Follow Charleston for a short distance.  You'll pass the
Metaphor/Kaleida buildings on the right.  At a clump of palm trees and
a "Landmark Deli" sign, take a right into Landings Drive.  At the end
of the road, turn left into the complex with the big concrete
"Landmark" sign.  Follow the road past the deli til you are in front
of the clock tower that rises out of one of the buildings, facing you.
Enter through the doors immediately under the clock tower.  They'll be
open between noon and 1PM at least.  (See below if you're late.)

Once inside, take the stairs up, immediately to your right.  At the top
of the stairs, turn right past the treetops, and we'll be in 1937 on 
your left.  The door is marked "Cygnus".

If you are late and the door under the clock tower is locked, you can
walk to the deli (which will be around the building on your left, as
you face the door).  Go through the gate in the fence to the right of
the deli, and into the back lawns between the complex and the farm
behind it.  Walk forward and right around the buildings until you see
a satellite dish in the lawn.  Go up the stairs next to the dish,
which are the back stairs into the Cygnus office space.  We'll prop
the door (or you can bang on it if we forget).

Or, you can find the guard who's wandering around the complex, who
knows there's a meeting happening and will let you in.  They can be
beeped at 965 5250, though you'll have trouble finding a phone.

Don't forget to eat first, or bring food at noon!  I recommend hitting
the burrito place on Rengstorff (La Costen~a) at about 11:45.  To get
there, when you get off 101, take Rengstorff (toward the hills) rather
than Amphitheatre (toward the bay).  Follow it about ten blocks until
the major intersection at Middlefield Road.  La Costen~a is the store
on your left at the corner.  You can turn left into the narrow lane
behind the store, which leads to a parking lot, and enter by the front
door, which faces the intersection.  To get to the meeting from there,
just retrace your route on Rengstorff, go straight over the freeway,
and turn right at the stoplight onto Charleston; see above.

See you there!

	John Gilmore







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 10 Dec 92 12:59:53 PST
To: cypherpunks@toad.com
Subject: Re: Tapes of Cypherpunks meeting?
In-Reply-To: <9212101813.AA19425@smds.com>
Message-ID: <9212102058.AA18076@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Steve Witham writes:

> Would it be possible to pay someone to video (or at least audio)
> tape this meeting (& others)--or at least the scheduled speakers?  
> I can imagine privacy concerns...  Maybe someone could
> get ready to do it and then ask the attendees whether it's okay,
> or under what arrangement.  There will definitely be people there
> with somewhat informed opinions on whether to trust me.

I doubt this will ever happen. Videotaping is a hassle, is even more
of a hassle when it comes to distributing the tapes, and is very
disruptive. People start mugging for the camera, or avoid speaking at
all. All in all, a bad idea.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Date: Thu, 10 Dec 92 11:03:58 PST
To: cypherpunks@toad.com
Subject: Re: 'token exchange' market in Arizona
Message-ID: <9212101903.AA12887@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


I participated in SFI's "Double Auction Tournament" a couple of years
ago, placing second.  Computer programs participated in a stock market
game, with individual buyers and sellers competing with each other to
make profit from fictional tokens.  The emphasis of the contest was on
computer trading strategies, not on monetary systems or computer
security.  

This new "token exchange" sounds like a continuation of the original
contest in which there will be an opportunity to compete and refine
strategies over a longer term.  It will probably be run from a central
server with minimal concern over security; these are economists
interested in stock market systems, not computer security people.

In the original contest, there was a prize pool of $10,000 divided
among the 30 contestants, with no contestant winning more than about
$500.  It seems likely that they'll have a similar bankroll for this
one, as an inducement for people to compete.


-- Marc Ringuette (mnr@cs.cmu.edu)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Thu, 10 Dec 92 12:26:02 PST
To: cypherpunks@toad.com
Subject: CHATTER Broadcast/Filter vs. "Fetching"
Message-ID: <9212101749.AA19315@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


Yanek Martinson basically says that the information that comes over the 
netnews right now is small enough that you could archive a couple weeks' 
worth on a gigabyte disk and put the rest on four DAT tapes per year.

True, but that's only the current rate of this particular channel.
Plus, most of the time I'd have to go back to tape.  But the real problem
here is that I haven't explained what I want instead.

I want all the archives of all the information in all media that have ever
been published and stored electronically (including on video and audio tape)
available at a second's notice.  That's the volume and access-time part of
it.  The other part is, how do I find what I want?  Yanek responds to me:

>>...I don't trust computer filters much.
>
>So how would you expect to know to "fetch" it?

Because I read one thing, and it says "in response to your article number
so-and-so," or, "Hey, folks, there's a great book on this over here."
In other words, following mentions in other things I see--things written
mostly by humans, at least at this point, but also published indexes
(manual or automatic) and guides.

That plus maybe a couple of low-bandwidth subscription setups like
magazines, and maybe one or two discussion groups like this one that I
would give full time attention to.

>> ...support distributed redundant archives,
>
>That's the current setup.
>
>> preferably with cross-checking. 
>
>What exactly do you mean by this?

That when I requested something, automatically a couple of storage sites
would be asked for its MD5 checksum, and my machine would check them against
each other and the actual data I got.
>
>> It would be even nicer if information could be stored, with
>> storage cost charged to the owner and/or readers,
>
>I don't think this would work too well.  Just because I answer someone's
>question on a newsgroup, I would not want to receive a bill for the
>storage.

The DAT system you describe has all the potential readers pay for the storage.
If they want to, then fine, but if not, and you don't want to either, that's 
fine, let your answer evaporate.  Someone always *is* paying.

>> and the rigamarole over creating new groups, and whether all the machines
>> between you and the center of the universe get all the groups, etc.
>
>Then get Len Rose's satellite dish (I did) and you can be pretty sure 
>you get all the newsgroups.

What's that cost, including electronics, modem, etc?  
Also, you didn't answer about the difficulty of creating groups.

-fnerd
store me now and quote me later
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Thu, 10 Dec 92 12:26:15 PST
To: cypherpunks@toad.com
Subject: crypto credits
Message-ID: <9212101749.AB19315@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


>need for a shorter term than "digital cash" for this cryptographic
>money.  He suggested "cryps".  I thought of "emoney" or "ecash" by
>analogy to "email".  Here's another one: "crydets", based on
>"credits".  Or maybe we should call them "Chaums"....

How about "crypto credits" or "quatloos?"

(And you're right about David Chaum, Dining Cryptographers and Digi Cash.)

-fnerd
quote me
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Thu, 10 Dec 92 12:24:49 PST
To: cypherpunks@toad.com
Subject: Tapes of Cypherpunks meeting?
Message-ID: <9212101813.AA19425@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


>Fourth Meeting
>
>When: Saturday, Dec 12, 1992, 12:00 noon
>Where: Cygnus Support offices

Would it be possible to pay someone to video (or at least audio)
tape this meeting (& others)--or at least the scheduled speakers?  
I can imagine privacy concerns...  Maybe someone could
get ready to do it and then ask the attendees whether it's okay,
or under what arrangement.  There will definitely be people there
with somewhat informed opinions on whether to trust me.

This brings up a fun concept: encrypted digital video and audio.
Would it be hard to do IDEA encryption at the standard CD rate?
There are schemes to compress video to that rate--how available
are they?  How much investment in equipment and crunch time do 
you need?  How easy is it to interrupt the bit streams in and out
of a DAT recorder?  How cheap is the decoder?

At present I would prefer VHS.

from out of nowhere
-fnerd
fnerd@smds.com (FutureNerd Steve Witham)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Robert Brooks <rb@hprrb.rose.hp.com>
Date: Thu, 10 Dec 92 14:36:21 PST
To: cypherpunks@toad.com
Subject: A/V compression
Message-ID: <9212102233.AA15517@hprrb.rose.hp.com>
MIME-Version: 1.0
Content-Type: text/plain


> 
> This brings up a fun concept: encrypted digital video and audio.
> Would it be hard to do IDEA encryption at the standard CD rate?
> There are schemes to compress video to that rate--how available
> are they?  How much investment in equipment and crunch time do 
> you need?  How easy is it to interrupt the bit streams in and out
> of a DAT recorder?  How cheap is the decoder?
> 

I picked this up off the net a while ago.  Sounds like the CL451 might
be programmable to do encryption/decryption, too.

Background:  MPEG is a compression standard for compressing VHS-quality
video and stereo audio into a 1.5Mbit/s stream.

If anyone's interested in funding/collaborating on a project involving
this, let's talk.


---
>From eletanjm@nuscc.nus.sg Fri Jul 10 21:06:25 1992
>Relay-Version: version Notes 2.8.4  1990/05/09; site hprpcd.rose.hp.com
>From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
>Date: Sat, 11 Jul 1992 04:06:25 GMT
>Date-Received: Sun, 12 Jul 1992 01:35:12 GMT
>Subject: NEW MPEG I CHIP
>Message-ID: <1992Jul11.040625.17239@nuscc.nus.sg>
>Organization: National University of Singapore
>Path: hprpcd!hprdash!hpergfg2!hpda!hpcc05!hplextra!hpscdc!sdd.hp.com!nigel.msen.com!yale.edu!jvnc.net!nuscc!eletanjm
>Newsgroups: comp.multimedia
>Lines: 23
>
>Has anyone seen a demo or read about the new MPEG chipset from C-Cube
>systems?
>
>I heard it's great!
>
>Some facts I know (or think I know)
>
>*       CL450 - is a decoder only
>*       CL451 - due out later this year is full encoder/decoder codec
>*       core is a RISC based processor with 36bit bus splittable into
>        4 data streams. 4 separate acc/mul units (ie SIMD).
>*       Can stream a full resolution video at ISA bus rates.
>*       Microcode and C compiler development kit.
>*       CL451 currently runs at 66MHz using fairly old .8 micron
>        technology ==> we can expect to see even higher speed devices.
>*       CL451 is pipelinable - ie can put multiple CL451 in tandem to
>        perform any amount of processor intensive activities. (eg real
>        time edge/motion detection, special effects etc).
>*       CL451 is a single chip solution. Just add VRAM.
>
>*       Largest demand so far - for Karaoke!! C-Cube has Jap. backers.
>
>jin meng
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~       Robert Brooks                           ~
~       Hewlett Packard Company                 ~
~       rb@hprpcd.rose.hp.com                   ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~       Robert Brooks                           ~
~       Hewlett Packard Company                 ~
~       rb@hprpcd.rose.hp.com                   ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Thu, 10 Dec 92 15:12:06 PST
To: cypherpunks@toad.com
Subject: MEETING: Cypherpunks UK (Sunday)
Message-ID: <6042@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


Announcing - on incredibly short notice! - the first meeting of
Cypherpunks UK...

Chris Tame, of FOREST and the Libertarian Alliance, has generously
offered the use of the meeting room at his offices for our gathering,
this Sunday, 13 December 1992, from 1200 onwards (at least until 1800),
at:

  FOREST
  4th Floor
  2 Grosvenor Gardens
  London   SW1W 0DH
  071-823-6550

This is just around the corner from Victoria Station, at the end of the
mansion block near Hobart Place.  There's a dark green cabbie shelter
across the street from the entrance, and some British Telecom payphones.
Can't miss it, really.  However, if you have trouble, call the telephone
number above, or call my pager, on 081-812-2661.

If it helps, we're in the direction of Buckingham Palace, which is
(very) partially visible from our windows.

If you wish to attend, you should bring a 3.5" DOS-formatted diskette
(sorry!  My UN*X machine is an Intergraph workstation, and I can't use
it for crypto) with a copy of your PGP 2.0+ public key.  I'll sign it
there.  Mac users: if you don't have Apple File Exchange (what!?), I'll
be extra nice and take your keys anyway ( ;-)) for AFE conversion on my
IIcx.  Not to fear.

It might not be a bad idea to copy your public key on each of several
diskettes, so you've got a copy to distribute to each of the others.
Don't trust me to copy *your* key to others!  As a matter of fact, as
there are plenty of power points in the meeting room, you should bring your
laptop, and/or a desktop PC:  when someone hands you a disk-with-key,
you can sign her key, and hand her back her diskette, with your own
pubkey added.

Otherwise, we might come close to a (n(n-1))/2 situation... ;-)

This should be a lively meeting.  Among the topics likely to be
discussed are:

  o   The proliferation of PGP public keys in the U.K.
  o   The local development of anonymous remailers and a proposed
        automatic public key repository
  o   Electronic networking/email security for the novice
  o   Pro-active proliferation of PGP 2.1+ to interesting European,
        African, and Asian sites
        -  ftp placement
        -  BBS distribution
        -  sneakernet across borders

.. and much more!

Mark Turner, from Demon Internet Systems, is likely to be on hand to
demo DIS for non-DIS users.  We've set up our own local, high-quality
newsgroups:
         demon.security
         demon.security.keys

and set up the /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding
recently to include all versions of PGP, and "fellow traveller" files).

There will be other people here whom I think you will find
interesting...  be seeing you!

Semper vigilans,

Russell Earl Whitaker                   whitaker@eternity.demon.co.uk
Communications Editor                       71750.2413@compuserve.com
EXTROPY: The Journal of Transhumanist Thought         AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
================ PGP 2.0 public key available =======================




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@cicada.berkeley.edu
Date: Thu, 10 Dec 92 23:20:55 PST
To: cypherpunks@toad.com
Subject: remailers
Message-ID: <9212110717.AA07396@cicada.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


This is another call for info from remailer operators.  I only heard from a
few of you.  Please send me info about how to use your remailer, including
the public key.  I will be setting up a special mailing list for remailer
operators so we can discuss the technical issues of remailing, so if you
mail me, you get on the list (if you want to).

Remember, the more remailers there are and the more they are used, the safer
it is for each individual remailer operator.  And people won't use them
unless they know how.  And they won't know how unless there's a directory of
them.

e
hh@soda.berkeley.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@rosebud.ee.uh.edu
Date: Thu, 10 Dec 92 21:24:21 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9212110524.AA22910@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Update on the digital cash project

I am having some problems with the port to MSDOS, mostly due to
implicitly assuming 32-bit integers in a few places.  Probably I won't
get it working until next weekend.

To recap, the program provides Chaum-style digital cash via two
executables, one for the "players" and one for the "banker".  The
banker creates a public key which has a single modulus n and multiple
exponents, the prime numbers starting with 17.  He sends n to the
players and all is ready.

Players withdraw money by running their programs and specifying the
denominations they want to withdraw.  For example, you could withdraw
a 1, two 5's, a 10 and a 20.  This would create a file with 5 entries
to be sent to the bank.  PGP should be used to encrypt and
ascii-encode this file (for privacy) and it should be mailed to the
banker.

The banker receives this file and runs his program to RSA-sign the
values in each of the withdrawal-request entries.  This is the
"blinded cash" that Chaum describes.  Again, PGP should be used for
mailing this back to the user.

The player then has to "unblind" the file to make it "real" digital
cash.  This also changes it so that the bank won't recognize it when
it is deposited.  He uses his version of the program to do this,
producing an actual digital money file with the five "digital bills"
in it.

To pay another user, he runs another function to extract the desired
bills from this file.  Suppose he wants to extract a 1 and a 5.  This
leaves a 5, a 10 and a 20 in the original file, and creates a new
digital cash file with a 1 and a 5.  He would then use PGP again to
encrypt this for safety and mail it to the person he wants to pay.

That person can run a "check" function on the incoming digital money
to make sure it has a proper bank signature on it and is not a
forgery.  He would then mail it directly to the bank so that it could
get credited to his account.

The banker runs his program which checks the signatures on the
incoming money, looks in a database file to make sure these bills
haven't been used before, and adds these bills to the database.  (The
database stores 16 bytes per bill.)  He should then record the deposit
and perhaps send a confirmation to the depositor (my program doesn't
get involved with that).

I hope this gives a clearer picture of how the electronic money
program works.  It is a simple implementation but I think many systems
would work similarly.

I appreciated the suggestion to use cash as part of the list
management itself.  Rather than paying people who post, I wonder if it
would be better to make people pay to post.  Many people have
complained about the volume.  :)  Unfortunately, I suspect that this
would involve too much overhead for the mailing list maintainer.

Maybe the thing to do is to just get the software out there and let
people decide what they want to do with it (if anything).  I'm
probably going to take a couple more weeks to clean up the user
interface and get these bugs out, then I'll try sending it someone to
be put on the cypherpunks ftp archive.

It's nice to be able to finally sign these messages!

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/
sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE
a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR
tAl4UGhhZWRydXM=
=HVRq
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyZADQrkCJ6S8691AQHneQP8DRdkOFfG9TwjGDJAX4IxymvzAITqYIJC
aMhytyzqFwP6Dku955ZHEPL1SDpNCU8DwK7eKDOgvHRS3m+kihs1l6VR3Gf0AgGw
7jjRJlt7hcqfT16fLHVXtn27A16rUhl2hKrD702wjGzX+MN7mS/8MW2kchVfvQYX
M/McOuwuIjs=
=/HGX
-----END PGP SIGNATURE-----




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Thu, 10 Dec 92 17:24:57 PST
To: cypherpunks@toad.com
Subject: Re: Questions about US/Canadian Laws about public encryption
In-Reply-To: <BysM6J.76z@minerva1.bull.it>
Message-ID: <mark.724036564@coombs>
MIME-Version: 1.0
Content-Type: text/plain


David Banisar <Banisar@washofc.cpsr.org> quotes:

>> (1) Is feeding public data or telephone networks with crypted data
>>     illegal or those who posted articles on the subject were just
>>     wishing it were made illegal ???

One might ask that they prove it is encrypted and not merely garbage your
pumping down the line to defeat traffic analysis attacks. I dont think it's
illegal so send garbage down a line assuming your paying for it and noone
is being defrauded by your use of the medium.

If you have good enough cryptography they cant prove it's encrypted. If they
managed to decode it to something that looks like text but isnt the original
cleartext then they are just grabbing at straws and not 'decrypting'.

If you choose to put the "standard" bytes in front and behind every block to
make it *look* like it's encrypted with a well known algorithm thats your
business.

To me proving it's encrypted amounts to decrypting it which is what your
trying to protect against. If they can prove the algorithm is weak then you
can just pay the fine and choose another method.

Mark
mark@coombs.anu.edu.au




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Thu, 10 Dec 92 17:31:26 PST
To: cypherpunks@toad.com
Subject: Re: Questions about US/Canadian Laws about public encryption
In-Reply-To: <BysM6J.76z@minerva1.bull.it>
Message-ID: <mark.724037151@coombs>
MIME-Version: 1.0
Content-Type: text/plain


On a discussion of devices one can attach to a phone line to encrypt
your comms:

rcain@netcom.com (Robert Cain) writes:

>There may be U.S. national security
>laws broad enough to stop a potential seller of such a device and I
>have been told that under such laws (of which I know little by definition)
>a stop order can be issued by a court which you must obey but can't even
>open because it carries a top secret seal and furthermore you cannot even
>discuss it without looking at Leavenworth.  So it is entirely possible that
>hidden laws exist to prevent sale of such devices, have been used and we
>would not know it under the umbrella of U.S. national security. 

So much for "ignorance of the law is no excuse". They want it both ways?
Secret laws and you obeying them? Sounds like the rules my roomies make up
as we play any board game. (aka cheating :)

Mark
mark@coombs.anu.edu.au




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: George A. Gleason <gg@well.sf.ca.us>
Date: Fri, 11 Dec 92 02:22:14 PST
To: mark@coombs.anu.edu.au
Subject: Re: Questions about US/Canadian Laws about public encryption
Message-ID: <199212111020.AA28057@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Any attempt at "secret law" in the US would be pretty straightforward to
defeat on the basis that it denies due process and a whole lot else besides.
 Secret court orders!  Retch!  Next person to get one should run not walk to
the offices of the nearest big newspaper or radio/TV station and do a live
on-air interview.  Then the govt has to take on the press as well, and by
that time it's kinda too late.  




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Fri, 11 Dec 92 10:10:54 PST
To: uunet!well.sf.ca.us!gg@uunet.UU.NET
Subject: Questions about US/Canadian Laws about public encryption
In-Reply-To: <199212111020.AA28057@well.sf.ca.us>
Message-ID: <9212111720.AA24204@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


	 Any attempt at "secret law" in the US would be pretty straightforward to
	 defeat on the basis that it denies due process and a whole lot else besides.
		Secret court orders!  Retch!  Next person to get one should run not walk to
	 the offices of the nearest big newspaper or radio/TV station and do a live
	 on-air interview.  Then the govt has to take on the press as well, and by
	 that time it's kinda too late.  

This worls in theory, but practice can be much more confusing.  For
instance, the warrant used to invade Steve Jackson Games was sealed,
so they couldn't see what was being looked for.  If you face a Grand
Jury, then you can't take the 5th (thus drug crimes are being pursued
by Grand Juries).  Etc.  I'm not prophesying gloom and doom (at least
not here :-), merely pointing out that what makes sense, what seems
ethical, what the theory of the law says, and what the practice of
the law says are all different, and it's quite easy to be wrong.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@pmantis.berkeley.edu
Date: Fri, 11 Dec 92 14:58:27 PST
To: cypherpunks@toad.com
Subject: Chaum's "The Dining Cryptographers Problem" (VERY LONG)
Message-ID: <9212112258.AA09353@pmantis.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


The following article is brought to you by the Information Liberation
Front (ILF), a group dedicated to the timely distribution of important
information. 

The ILF encourages you to use this article for educational purposes
only and to seek out the original article. Minor spelling errors and
slight alterations of formulas may have gotten past the OCR process.

We apologize for the length, but feel this is one of the key articles
in this area. 


J. Cryptology (1988) 1:65-75

The Dining Cryptographers Problem:

Unconditional Sender and Recipient Untraceability

David Chaum
Centre for Mathematics and Computer Science, Kruislan 413, 1098 SJ 
Amsterdam, The Netherlands

Abstract.  Keeping confidential who sends which messages, in a 
world where any physical transmission can be traced to its 
origin, seems impossible. The solution presented here is 
unconditionally or cryptographically secure, depending on whether 
it is based on one-time-use keys or on public keys, respectively. 
It can be adapted to address efficiently a wide variety of 
practical considerations.

Key words.  Untraceability, Unconditional Security, Pseudonymity.

Introduction

Three cryptographers are sitting down to dinner at their favorite 
three-star restaurant. Their waiter informs them that arrangements 
have been made with the maitre d'hotel for the bill to be paid 
anonymously. One of the cryptographers might be paying for the dinner, 
or it might have been NSA (U.S. National Security Agency). The three 
cryptographers respect each other's right to make an anonymous 
payment, but they wonder if NSA is paying. They resolve their 
uncertainty fairly by carrying out the following protocol:

Each cryptographer flips an unbiased coin behind his menu, between 
him and the cryptographer on his right, so that only the two of them can 
see the outcome. Each cryptographer then states aloud whether the two 
coins he can see--the one he flipped and the one his left-hand neighbor 
flipped--fell on the same side or on different sides. If one of the 
cryptographers is the payer, he states the opposite of what he sees. An 
odd number of differences uttered at the table indicates that a 
cryptographer is paying; an even number indicates that NSA is paying 
(assuming that the dinner was paid for only once). Yet if a 
cryptographer is paying, neither of the other two learns anything from 
the utterances about which cryptographer it is.

To see why the protocol is unconditionally secure if carried out 
faithfully, consider the dilemma of a cryptographer who is not the 
payer and wishes to find out which cryptographer is. (If NSA pays, there 
is no anonymity problem.) There are two cases. In case (1) the two 
coins he sees are the same, one of the other cryptographers said 
"different," and the other one said "same." If the hidden outcome was 
the same as the two outcomes he sees, the cryptographer who said 
"different" is the payer; if the outcome was different, the one who said 
"same" is the payer. But since the hidden coin is fair, both possibilities 
are equally likely. In case (2) the coins he sees are different; if both 
other cryptographers said "different," then the payer is closest to the 
coin that is the same as the hidden coin; if both said "same," then the 
payer is closest to the coin that differs from the hidden coin. Thus, in 
each subcase, a nonpaying cryptographer learns nothing about which of 
the other two is paying.

The cryptographers become intrigued with the ability to make 
messages public untraceably. They devise a way to do this at the table 
for a statement of arbitrary length: the basic protocol is repeated over 
and over; when one cryptographer wishes to make a message public, he 
merely begins inverting his statements in those rounds corresponding 
to 1 's in a binary coded version of his message. If he notices that his 
message would collide with some other message, he may for example 
wait a number of rounds chosen at random from a suitable distribution 
before trying to transmit again.

1. Generalizing the Approach

During dinner, the cryptographers also consider how any number of 
participants greater than one can carry out a version of the protocol. 
(With two participants, only nonparticipant listeners are unable to 
distinguish between the two potential senders.) Each participant has a 
secret key bit in common with, say, every other participant. Each 
participant outputs the sum, modulo two, of all the key bits he shares, 
and if he wishes to transmit, he inverts his output. If no participant 
transmits, the modulo two sum of the outputs must be zero, since every 
key bit enters exactly twice; if one participant transmits, the sum 
must be one. (In fact, any even number of transmitting participants 
yields zero, and any odd number yields one.) For j rounds, each 
participant could have a j-bit key in common with every other 
participant, and the ith bit of each such key would be used only in the 
ith round. Detected collision of messages leads to attempted 
retransmission as described above; undetected collision results only 
from an odd number of synchronized identical message segments. 
(Generalization to fields other than GF(2) is possible, but seems to 
offer little practical advantage.)

Other generalizations are also considered during dinner. The 
underlying assumptions are first made explicit, including modeling 
key-sharing arrangements as graphs. Next, the model is illustrated 
with some simple examples. The potential for cooperations of 
participants to violate the security of others is then looked at. Finally, 
a proof of security based on systems of linear equations is given.

1.1. Model

Each participant is assumed to have two kinds of secret: (a) the keys 
shared with other participants for each round; and (b) the inversion 
used in each round (i.e., a 1 if the participant inverts in that round and a 
0 if not). Some or all of a participant's secrets may be given to other 
participants in various forms of collusion, discussion of which is 
postponed until Section 1.3. (For simplicity in exposition, the 
possibility of secrets being stolen is ignored throughout.)

The remaining information about the system may be described as: (a)
who shares keys with whom; and (b) what each participant outputs
during each round (the modulo two sum of that participant's keys and
inversion). This information need not be secret to ensure
untraceability. If it is publicly known and agreed, it allows various
extensions discussed in Sections 2.5 and 2.6. The sum of all the
outputs will, of course, usually become known to all participants.

In the terminology of graphs, each participant corresponds to a 
vertex and each key corresponds to an edge. An edge is incident on the 
vertices corresponding to the pair of participants that shares the 
corresponding key. From here on, the graph and dinner-table 
terminologies will be used interchangeably. Also, without loss of 
generality, it will be assumed that the graph is connected (i.e., that a 
path exists between every pair of vertices), since each connected 
component (i.e., each maximal connected subgraph) could be considered 
a separate untraceable-sender system.

An anonymity set seen by a set of keys is the set of vertices in a 
connected component of the graph formed from the original graph by 
removing the edges concerned. Thus a set of keys sees one anonymity 
set for each connected partition induced by removing the keys. The main 
theorem of Section 1.4 is essentially that those having only the public 
information and a set of keys seeing some anonymity set can learn 
nothing about the members of that anonymity set except the overall 
parity of their inversions. Thus, for example, any two participants 
connected by at least one chain of keys unknown to an observer are both 
in the same anonymity set seen by the observer's keys, and the observer 
gains nothing that would help distinguish between their messages.

1.2. Some Examples

A few simple consequences of the above model may be illustrative. The 
anonymity set seen by the empty set (i.e., by a nonparticipant observer) 
is the set of all vertices, since the graph is assumed connected and 
remains so after zero edges are removed. Also, the anonymity sets seen 
by the full set of edges are all singleton sets, since each vertex's 
inversion is just the sum of its output and the corresponding key bits.

If all other participants cooperate fully against one, of course no 
protocol can keep that singleton's messages untraceable, since 
untraceability exists only among a set of possible actors, and if the set 
has only one member, its messages are traceable. For similar reasons, 
if a participant believes that some subset of other participants will 
fully cooperate against him, there is no need for him to have keys in 
common with them.

A biconnected graph (i.e., a graph with at least two vertex-disjoint 
paths between every pair of vertices) has no cut-vertices (i.e., a single 
vertex whose removal partitions the graph into disjoint subgraphs). In 
such a graph, the set of edges incident on a vertex v sees (apart from v) 
one anonymity set containing all other vertices, since there is a path 
not containing v between every pair of vertices, and thus they form a 
connected subgraph excluding v; each participant acting alone learns 
nothing about the contribution of other participants.

1.3. Collusion of Participants

Some participants may cooperate by pooling their keys in efforts to 
trace the messages of others; such cooperation will be called collusion. 
For simplicity, the possibilities for multiple collusions or for pooling 
of information other than full edges will be ignored. Colluders who lie 
to each other are only touched on briefly, in Section 2.6.

Consider collusion in a complete graph. A vertex is only seen as a 
singleton anonymity set by the collection of all edges incident on it; all 
other participants must supply the key they share with a participant in 
order to determine that participant's inversions. But since a collusion 
of all but one participant can always trace that participant merely by 
pooling its members' inversions as already mentioned, it gains nothing 
more by pooling its keys. The nonsingleton anonymity set seen by all 
edges incident on a colluding set of vertices in a complete graph is the 
set of all other vertices; again, a collusion yields nothing more from 
pooling all its keys than from pooling all its inversions.

Now consider noncomplete graphs. A full collusion is a subset of 
participants pooling all of their keys. The pooled keys see each colluder 
as a singleton anonymity set; the colluders completely sacrifice the 
untraceability of their own messages. If a full collusion includes a cut-
set of vertices (i.e., one whose removal partitions the graph), the 
collusion becomes nontrivial because it can learn something about the 
origin of messages originating outside the collusion; the noncolluding 
vertices are partitioned into disjoint subgraphs, which are the 
anonymity sets seen by the pooled keys.

Members of a partial collusion pool some but not all of their keys. 
Unlike the members of a full collusion, each member of a partial 
collusion in general has a different set of keys. For it to be nontrivial, 
a partial collusion's pooled keys must include the bridges or separating 
edges of a segregation or splitting of the graph (i.e., those edges whose 
removal would partition the graph). Settings are easily constructed in 
which the pooled keys see anonymity sets that partition the graph and 
yet leave each colluder in a nonsingleton partition seen by any other 
participant. Thus, colluders can join a collusion without having to make 
themselves completely traceable to the collusion's other members.

1.4. Proof of Security

Consider, without loss of generality, a single round in which say some 
full collusion knows some set of keys. Remove the edges known to the 
collusion from the key-sharing graph and consider any particular 
connected component C of the remaining graph. The vertices of C thus 
form an anonymity set seen by the pooled keys.

Informally, what remains to be shown is that the only thing the 
collusion learns about the members of C is the parity sum of their 
inversions. This is intuitively apparent, since the inversions of the 
members of C are each in effect hidden from the collusion by one or 
more unknown key bits, and only the parity of the sum of these key bits 
is known (to be zero). Thus the inversions are hidden by a one-time pad, 
and only their parity is revealed, because only the parity of the pad is 
known.

The setting is formalized as follows: the connected component C is 
comprised of rn vertices and n edges. The incidence matrix M of C is 
defined as usual, with the vertices labeling the rows and the edges 
labeling the columns. Let K, I, and A be stochastic variables defined on 
GF(2)^n, GF(2)^m, and GF(2)^m, respectively, such that
K is uniformly distributed over GF(2)^n, K and I are mutually 
independent, and A = (MK) cross I. In terms of the protocol, K comprises 
the keys corresponding to the edges, I consists of the inversions 
corresponding to the vertices, and A is formed by the outputs of the 
vertices. Notice that the parity of A (i.e., the modulo two sum of its 
components) is always equal to the parity of I, since the columns of M 
each have zero parity. The desired result is essentially that A reveals 
no more information about I than the parity of 1. More formally:

Theorem.  Let a be in GF(2)^n. For each i in GF(2)^n, which is assumed by 
I with nonzero probability and which has the same parity as a, the 
conditional probability that A = a given that I = i is 2^(1 - m). Hence, 
the conditional probability that I = i given that A = a is the a priori 
probability that I = i.

Proof.  Let i be an element of GF(2)^n have the same parity as a. 
Consider the system of linear equations (MK) cross i = a, in k an 
element of GF(2)^n. Since the columns of M each have even parity, as 
mentioned above, its rows are linearly dependent over GF(2)^m. But as a 
consequence of the connectedness of the graph, every proper subset of 
rows of M is linearly independent. Thus, the rank of M is m - 1, and so 
each vector with zero parity can be written as a linear combination of 
the columns of M. This implies that the system is solvable because i 
cross a has even parity. Since the set of n column vectors of M has rank 
m - 1, the system has exactly 2^(n - m + 1) solutions.

Together with the fact that K and I are mutually independent and 
that K is uniformly distributed, the theorem follows easily.                           

2. Some Practical Considerations

After dinner, while discussing how they can continue to make 
untraceable statements from this respective homes, the cryptographers 
take up a variety of other topics. In particular, they consider different 
ways to establish the needed keys; debate adapting the approach to 
various kinds of communication networks; examine the traditional 
problems of secrecy and authentication in the context of a system that 
can provide essentially optimal untraceability; address denial of 
service caused by malicious and devious participants; and propose 
means to discourage socially undesirable messages from being sent.

2.1. Establishing Keys

One way to provide the keys needed for longer messages is for one 
member of each pair to toss many coins in advance. Two identical 
copies of the resulting bits are made, say each on a separate optical 
disk. Supplying one such disk (which today can hold on the order of 
10^10 bits) to a partner provides enough key bits to allow people to 
type messages at full speed for years. If participants are not 
transmitting all the time, the keys can be made to last even longer by 
using a substantially slower rate when no message is being sent; the 
full rate would be invoked automatically only when a 1 bit indicated 
the beginning of a message. (This can also reduce the bandwidth 
requirements discussed in Section 2.2.)

Another possibility is for a pair to establish a short key and use a 
cryptographic pseudorandom-sequence generator to expand it as needed. 
Of course this system might be broken if the generator were broken. 
Cryptanalysis may be made more difficult, however, by lack of access 
to the output of individual generators. Even when the cryptographers do 
not exchange keys at dinner, they can safely do so later using a public-
key distribution system (first proposed by [4] and [3]).

2.2 Underlying Communication Techniques

A variety of underlying communication networks can be used, and their 
topology need not be related to that of the key-sharing graph.

Communication systems based on simple cycles, called rings, are 
common in local area networks. In a typical ring, each node receives 
each bit and passes it round-robin to the next node. This technology is 
readily adapted to the present protocols. Consider a single-bit message 
like the "I paid" message originally sent at the dinner table. Each 
participant exclusive-or's the bit he receives with his own output 
before forwarding it to the next participant. When the bit has traveled 
full circle, it is the exclusive-or sum of all the participants' outputs, 
which is the desired result of the protocol. To provide these messages 
to all participants, each bit is sent around a second time by the 
participant at the end of the loop.

Such an adapted ring requires, on average, a fourfold increase in 
bandwidth over the obvious traceable protocols in which messages 
travel only halfway around on average before being taken off the ring by 
their recipients. Rings differ from the dinner table in that several bit-
transmission delays may be required before all the outputs of a 
particular round are known to all participants; collisions are detected 
only after such delays.

Efficient use of many other practical communication techniques 
requires participants to group output bits into blocks. For example, in 
high-capacity broadcast systems, such as those based on coaxial cable, 
surface radio, or satellites, more efficient use of channel capacity is 
obtained by grouping a participant's contribution into a block about the 
size of a single message (see, e.g., [5]). Use of such communication 
techniques could require an increase in bandwidth on the order of the 
number of participants.

In a network with one message per block, the well-known contention 
protocols can be used: time is divided evenly into frames; a participant 
transmits a block during one frame; if the block was garbled by 
collision (presumably with another transmitted block), the participant 
waits a number of frames chosen at random from some distribution 
before attempting to retransmit; the participants' waiting intervals 
may be adjusted on the basis of the collision rate and possibly of other 
heuristics [5].

In a network with many messages per block, a first block may be 
used by various anonymous senders to request a "slot reservation" in a 
second block. A simple scheme would be for each anonymous sender to 
invert one randomly selected bit in the first block for each slot they 
wish to reserve in the second block. After the result of the first block 
becomes known, the participant who caused the ith 1 bit in the first 
block sends in the ith slot of the second block.

2.3. Example Key-Sharing Graphs

In large systems it may be desirable to use fewer than the m(m - 1)/2 
keys required by a complete graph. If the graph is merely a cycle, then 
individuals acting alone learn nothing, but any two colluders can 
partition the graph, perhaps fully compromising a participant 
immediately between them. Such a topology might nevertheless be 
adequate in an application in which nearby participants are not likely 
to collude against one another.

A different topology assumes the existence of a subset of 
participants who each participant believes are sufficiently unlikely to 
collude, such as participants with conflicting interests. This subset 
constitutes a fully connected subgraph, and the other participants each 
share a key with every member of it. Every participant is then 
untraceable among all the others, unless all members of the completely 
connected subset cooperate. (Such a situation is mentioned again in 
Section 3.)

If many people wish to participate in an untraceable communication 
system, hierarchical arrangements may offer further economy of keys. 
Consider an example in which a representative from each local fully 
connected subgraph is also a member of the fully connected central 
subgraph. The nonrepresentative members of a local subgraph provide 
the sum of their outputs to their representative. Representatives would 
then add their own contributions before providing the sum to the 
central subgraph. Only a local subgraph's representative, or a collusion 
of representatives from all other local subgraphs, can recognize 
messages as coming from the local subgraph. A collusion comprising 
the representative and all but one nonrepresentative member of a local 
subgraph is needed for messages to be recognized as coming from the 
remaining member.

2.4. Secrecy and Authentication

What about the usual cryptologic problems of secrecy and 
authentication?

A cryptographer can ensure the secrecy of an anonymous message by 
encrypting the message with the intended recipient's public key. (The 
message should include a hundred or so random bits to foil attempts to 
confirm a guess at its content [1].) The sender can even keep the 
identity of the intended recipient secret by leaving it to each recipient 
to try to decrypt every message. Alternatively, a prearranged prefix 
could be attached to each message so that the recipient need only 
decrypt messages with recognized prefixes. To keep even the 
multiplicity of a prefix's use from being revealed, a different prefix 
might be used each time. New prefixes could be agreed in advance, 
generated cryptographically as needed, or supplied in earlier messages.

Authentication is also quite useful in systems without identification.
Even though the messages are untraceable, they might still bear
digital signatures corresponding to public-key "digital pseudonyms"
[1]; only the untraceable owner of such a pseudonym would be able to
sign subsequent messages with it. Secure payment protocols have
elsewhere been proposed in which the payer and/or the payee might be
untraceable [2]. Other protocols have been proposed that allow
individuals known only by pseudonyms to transfer securely information
about themselves between organizations [2]. All these systems require
solutions to the sender untraceability problem, such as the solution
presented here, if they are to protect the unlinkability of pseudonyms
used to conduct transactions from home.

2.5. Disruption

Another question is how to stop participants who, accidentally or even 
intentionally, disrupt the system by preventing others from sending 
messages. In a sense, this problem has no solution, since any 
participant can send messages continuously, thereby clogging the 
channel. But nondisupters can ultimately stop disruption in a system 
meeting the following requirements: (1) the key-sharing graph is 
publicly agreed on; (2) each participant's outputs are publicly agreed on 
in such a way that participants cannot change their output for a round 
on the basis of other participants' outputs for that round; and (3) some 
rounds contain inversions that would not compromise the 
untraceability of any nondisrupter.

The first requirement has already been mentioned in Section 1.1, 
where it was said that this information need not be secret; now it is 
required that this information actually be made known to all 
participants and that the participants agree on it.

The second requirement is in part that disrupters be unable (at least 
with some significant probability) to change their output after hearing 
other participants' outputs. Some actual channels would automatically 
ensure this, such as broadcast systems in which all broadcasts are 
made simultaneously on different frequencies. The remainder of the 
second requirement, that the outputs be publicly agreed on, might also 
be met by broadcasting. Having only channels that do not provide it 
automatically, an effective way to meet the full second requirement 
would be for participants to "commit" to their outputs before making 
them. One way to do this is for participants to make public and agree on 
some (possibly compressing and hierarchical, see Section 2.6) one-way 
function of their outputs, before the outputs are made public.

The third requirement is that at least some rounds can be contested 
(i.e., that all inversions can be made public) without compromising the 
untraceability of non-disrupting senders. The feasibility of this will be 
demonstrated here by a simple example protocol based on the slot 
reservation technique already described in Section 2.2.

Suppose that each participant is always to make a single reservation 
in each reserving block, whether or not he actually intends to send a 
message. (Notice that, because of the "birthday paradox," the number of 
bits per reserving block must be quadratic in the number of 
participants.) A disrupted reserving block would then with very high 
probability have Hamming weight unequal to the number of participants. 
All bits of such a disrupted reserving block could be contested without 
loss of untraceability for nondisrupters.

The reserved blocks can also be made to have such safely contestable
bits if participants send trap messages. To lay a trap, a participant
first chooses the index of a bit in some reserving block, a random
message, and a secret key. Then the trapper makes public an
encryption, using the secret key, of both the bit index and the random
message. Later, the trapper reserves by inverting in the round
corresponding to the bit index, and sends the random message in the
resulting reserved slot. If a disrupter is unlucky enough to have
damaged a trap message, then release of the secret key by the trapper
would cause at least one bit of the reserved slot to be contested.

With the three requirements satisfied, it remains to be shown how 
if enough disrupted rounds are contested, the disrupters will be 
excluded from the network.

Consider first the case of a single participant's mail computer 
disrupting the network. If it tells the truth about contested key bits it 
shares (or lies about an even number of bits), the disrupter implicates 
itself, because its contribution to the sum is unequal to the sum of 
these bits (apart from any allowed inversion). If, on the other hand, the 
single disrupter lies about some odd number of shared bits, the values 
it claims will differ from those claimed for the same shared bits by 
the other participants sharing them. The disrupter thereby casts 
suspicion on all participants, including itself, that share the disputed 
bits. (It may be difficult for a disrupter to cast substantial suspicion 
on a large set of participants, since all the disputed bits will be in 
common with the disrupter.) Notice, however, that participants who 
have been falsely accused will know that they have been--and by 
whom--and should at least refuse to share bits with the disrupter in 
the future.

Even with colluding multiple disrupters, at least one inversion must 
be revealed as illegitimate or at least one key bit disputed, since the 
parity of the outputs does not correspond to the number of legitimate 
inversions. The result of such a contested round will be the removal of 
at least one edge or at least one vertex from the agreed graph. Thus, if 
every disruptive action has a nonzero probability of being contested, 
only a bounded amount of disruption is possible before the disrupters 
share no keys with anyone in the network, or before they are revealed, 
and are in either case excluded from the network.

The extension presented next can demonstrate the true value of 
disputed bits, and hence allows direct incrimination of disrupters.

2.6. Tracing by Consent

Antisocial use of a network can be deterred if the cooperation of most 
participants makes it possible, albeit expensive, to trace any message. 
If, for example, a threatening message is sent, a court might order all 
participants to reveal their shared key bits for a round of the message. 
The sender of the offending message might try to spread the blame, 
however, by lying about some odd number of shared bits. Digital 
signatures can be used to stop such blame-spreading altogether. In 
principle, each party sharing a key could insist on a signature, made by 
the other party sharing, for the value. of each shared bit.

Such signatures would allow for contested rounds to be fully resolved,
for accused senders to exonerate themselves, and even for colluders to
convince each other that they are pooling true keys.  Unfortunately,
cooperating participants able to trace a message to its sender could
convince others of the message's origin by revealing the sender's own
signatures. A variation can prevent a participant's signatures from
being used against him in this way: instead of each member of a pair
of participants signing the same shared key bit, each signs a separate
bit, such that the sum of the signed bits is the actual shared key
bit. Signatures on such "split" key bits would still be useful in
resolving contested rounds, since if one contester of a bit shows a
signature made by the second contester, then the second would have to
reveal the corresponding signature made by the first or be thought to
be a disrupter.

In many applications it may be impractical to obtain a separate 
signature on every key bit or split key bit. The overhead involved could 
be greatly reduced, however, by digitally signing cryptographic 
compressions of large numbers of key bits. This might of course require 
that a whole block of key bits be exposed in showing a signature, but 
such blocks could be padded with cryptographically generated 
pseudorandom (or truly random) bits, to allow the exposure of fewer 
bits per signature. The number of bits and amount of time required to 
verify a signature for a single bit can be reduced further by using a 
rooted tree in which each node is the one-way compression function of 
all its direct descendants; only a digital signature of each participant's 
root need be agreed on before use of the keys comprising the leaves.

3. Relation to Previous Work

There is another multiparty-secure sender-untraceability protocol in 
the literature [1]. To facilitate comparison, it will be called a mix-net 
here, while the protocol of the present work is called a dc-net. The 
mix-net approach relies on the security of a true public-key system 
(and possibly also of a conventional cryptosystem), and is thus at best 
computationally secure; the dc-net approach can use unconditional 
secrecy channels to provide an unconditionally secure untraceable-
sender system, or can use public-key distribution to provide a 
computationally secure system (as described in Section 2.1).

Under some trust assumptions and channel limitations, however, 
mix-nets can operate where dc-nets cannot. Suppose that a subset of 
participants is trusted by every other participant not to collude and 
that the bandwidth of at least some participants' channels to the 
trusted subset is incapable of handling the total message traffic. Then 
mix-nets may operate quite satisfactorily, but dc-nets will be unable 
to protect fully each participant's untraceability. Mix-nets can also 
provide recipient untraceability in this communication environment, 
even though there is insufficient bandwidth for use of the broadcast 
approach (mentioned in Section 2.4).

If optimal protection against collusion is to be provided and the 
crypto-security of mix-nets is acceptable, a choice between mix-nets 
and dc-nets may depend on the nature of the traffic. With a mail-like 
system that requires only periodic deliveries, and where the average 
number of messages per interval is relatively large, mix-nets may be 
suitable. When messages must be delivered continually and there is no 
time for batching large numbers of them, dc-nets appear preferable.

4. Conclusion

This solution to the dining cryptographers problem demonstrates that
unconditional secrecy channels can be used to construct an
unconditional sender-untraceability channel. It also shows that a
public-key distribution system can be used to construct a
computationally secure sender-untraceability channel. The approach
appears able to satisfy a wide range of practical concerns.

Acknowledgments

I am pleased to thank Jurjen Bos, Gilles Brassard, Jan-Hendrik Evertse, 
and the untraceable referees for all their help in revising this article. 
It is also a pleasure to thank, as in the original version that was 
distributed at Crypto 84, Whitfield Diffie, Ron Rivest, and Gus Simmons 
for some stimulating dinner-table conversations.

References

[1]	Chaum, D., Untraceable Electronic Mail, Return Addresses, and 
Digital Pseudonyms, Communications of the  ACM, vol. 24, no. 2, 
February 1981, pp. 84-88.
[2]	Chaum, D., Security Without Identification: Transaction Systems 
to Make Big Brother Obsolete, Communications of the ACM, vol. 28, 
no. 10, October 1985, pp. 1030-1044.
[3]	Diffie, W., and Hellman, M.E., New Directions in Cryptography, IEEE 
Transactions on Information Theory, vol. 22, no. 6, November 1976, 
pp. 644-654.
[4]	Merkle, R.C., Secure Communication over Insecure Channels, 
Communications of the ACM, vol. 21, no. 4, 1978, pp. 294-299.
[5]	Tanenbaum, A.S., Computer Networks, Prentice Hall, Englewood 
Cliffs, New Jersey, 1981.


[End of Transmission]



-- 









From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eli Brandt <ebrandt@jarthur.Claremont.EDU>
Date: Fri, 11 Dec 92 15:39:32 PST
To: cypherpunks@toad.com
Subject: YA remailer
Message-ID: <9212112339.AA11270@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


I have a Hal-standard remailer running at this address,
ebrandt@jarthur.claremont.edu -- haven't compiled PGP
on this silly Sequent box yet, so no ARA's.

	 PGP 2 key by finger or e-mail    (and finger works now)
   Eli   ebrandt@jarthur.claremont.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill O'Hanlon <wmo@rebma.rebma.mn.org>
Date: Fri, 11 Dec 92 18:27:14 PST
To: cypherpunks@toad.com
Subject: keys for me and remailer@rebma.mn.org
Message-ID: <m0n0MGM-0006XZC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


I don't know how much use this is, since no one has signed my key, but here
it is, plus the key for the remailer here at rebma, signed by me.

If anyone is going to be in the Minneapolis area, lemme know.

Here's mine:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAirR6jkAAAEEAOMZFXG8bGGSpctmszxLug8IoLi55pUy+gR81K6ZBfLOmrTh
XCeuSBZ+yi6IZXuabOTsKo9r6wHVAvumZlfMvcp9Jbasp6Lc756aacsatHYsiQR4
7feUmp/coOyZ4ZfAXCmapc3dozYB9vWoWMhQy8QmWhotR8zTLRlm7A4meZALAAUR
tCBXYXJyaW9yIDx3bW9AcmVibWEubW4ub3JnPiBrZXkgMg==
=3/XA
-----END PGP PUBLIC KEY BLOCK-----
And here's the remailers:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD
WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b
yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR
tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKYkAlQIFECsUJGEYkFR3
jlSfhwEB1zgD/1LG9DttNEVPFddxkULPw+AkkbmSolrqJUmVx/3y3QS1AtW+vVqF
0yhgWgvg770b7+xMnwzO/I1nh0FK2shd1Jkx4FVCA5ctyqUzVFjk1NE6VaaRc5Bv
BD1nUxtUheR0WXDc50f+ANHgRNkx22MGRvphseMyXq/Ok88opSn7DIrO
=nBQt
-----END PGP PUBLIC KEY BLOCK-----
-- 
Bill O'Hanlon						 wmo@rebma.mn.org



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 12 Dec 92 09:50:58 PST
To: cypherpunks@toad.com
Subject: (fwd) EFFector Online 4.00
Message-ID: <9212121749.AA20077@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

Cypherpunks,

Here's the latest EFFector Online, which happens to have stuff about two of
us, John Gilmore and me, and which mentions Tom Jennings! No
mention of our little group, yet, but I expect we can't hide for long.

--Tim May

From: rita@eff.org (Rita Marie Rouvalis)
Subject: EFFector Online 4.00
Followup-To: comp.org.eff.talk
Originator: rita@eff.org
Keywords: crypto, nsa, pioneer wards
Organization: Electronic Frontier Foundation
Date: Fri, 11 Dec 1992 20:00:04 GMT


########## ########## ########## |
########## ########## ########## |         GILMORE VS. THE NSA
####       ####       ####       |
########   ########   ########   |
########   ########   ########   |   THE CRYPTO ANARCHIST MANIFESTO
####       ####       ####       |
########## ####       ####       |  2nd PIONEER AWARDS DEADLINE LOOMS
########## ####       ####       |
=====================================================================
EFFector Online           December 11, 1992               Issue  4.00
           A Publication of the Electronic Frontier Foundation
                            ISSN 1062-9424
=====================================================================


                      ACCESSING THE NSA
 JOHN GILMORE FILES SUIT WITH THE NATIONAL SECURITY AGENCY


At the beginning of July 1992, John Gilmore filed a FOIA request
with NSA asking for access to parts of cryptologic treatises
written by NSA personnel:  Military Cryptanalysis, Parts III
and IV, by William Friedman (WF-3/4); and Military
Cryptanalytics, Parts III-VI, by William Friedman and
Lambros Callimahos (LC3-6).

Parts I and II of each of these treatises had already been
declassified and published.  At the time of the request, it
was not definitely known whether the parts requested by
Gilmore had been re-classified.    

Under the FOIA, agencies are required to communicate
responses to requesters within statutorily prescribed time
periods.  Failure to comply with the time limits for response
constitutes a denial of the request, giving the requester the
right to appeal.

When NSA violated the first applicable time period,
Gilmore filed an administrative appeal with the NSA's FOIA
appeals authority.  There is also a time limit for response
to such appeals.  After this time limit passed without a
response from the NSA's appeals authority, Gilmore filed
a complaint in federal court in the Northern District of
California on Sept. 4, 1992, as permitted by the FOIA.

Gilmore's complaint alleged three claims:  First, that the
NSA improperly withheld these documents from him, and
had no legal basis for withholding; second, that the NSA's
failure to comply with the FOIA time limits constituted a
form of improper withholding; and third, that the NSA in
general engages in an illegal pattern or practice of routinely
violating the FOIA time limits, which should be declared
illegal and enjoined.

In the period between the initial FOIA request to NSA, and
the filing of the complaint in federal court, Gilmore obtained
copies of two of the withheld documents:  Military
Cryptanalysis Parts III and IV, by Friedman.  These copies
were discovered in libraries accessible to the general
public and were provided by these libraries without any
kind of restriction.  Gilmore intended to get expert opinion
on the national security risk posed by disclosure of these
documents.  He also reasoned that their very availability
in such libraries demonstrated that there could be no legal
basis for withholding them from a FOIA requester.

At the time the documents were obtained, Gilmore had not
received any indication from NSA that the documents were
classified.  It was therefore possible that the documents
were not, in fact, classified.  In addition, FOIA requests for
documents generally trigger agency declassification review.
Thus, even if the documents were in fact classified at the
time of the request, it was possible that NSA would decide
that they should no longer be classified, and release them
to Gilmore.

After the complaint was filed, Gilmore not only served the
complaint upon NSA, he also served a number of discovery
requests upon NSA, seeking to discover information about
both the history of these documents and about NSA's FOIA
processing procedures.

In early October, after NSA had received the complaint and
the discovery requests, NSA finally sent its responses to
the FOIA request.  NSA informed Gilmore that the documents
were not going to be released to him.  NSA said that it had
located WF-3/4 and LC-3, but that LC-4/5/6 had never been
completed because of the death of Lambros Callimahos.

First, NSA asserted that the three documents which did
exist were classified.  WF-3/4 were classified CONFIDENTIAL,
the lowest level of classification under Executive Order
12,356 governing classified information.  LC-3 was
classified SECRET, the middle level of classification.

Under the FOIA, an agency may withhold documents if they
are properly classified for reasons of national security.

Second, NSA asserted that the documents could also be
withheld under a different exemption in the FOIA.  Under the
(b)(3) exemption, documents may be withheld if there exists
a statute which authorizes an agency to withhold them.  NSA
pointed to several statutes which arguably covered this
material.  One of these statutes, 18 U.S.C. Section 798,
makes it a federal crime knowingly to disclose classified 
cryptologic or communications intelligence information to
unauthorized persons.

At this point, it became clear to Gilmore that there was a
problem.  He now knew for a fact that the documents he had
were classified (WF-3/4) and that it would be a crime for
him to disseminate them.  He could no longer continue with
his plan of showing them to other persons for fear of
criminal prosecution.  He also feared that should NSA ever
discover that he possessed them, he would be subjected to
search and seizure and the copies confiscated.  (Note that
although the First Amendment Privacy Protection Act
generally protects the press against search and seizure
for materials intended for publication where the crime
involves mere possession or dissemination of information,
it does not apply to any materials covered by the espionage
statutes, of which 18 U.S.C. Section 798 is one.)

NSA did not, however, know that he had them.  Gilmore
decided that the best course of action was to submit copies
of WF-3/4 to the federal district court under seal.  By so
doing, he would ensure that at least these copies would be
kept out of the NSA's hands, since it was unlikely that a federal
judge would relinquish possession of documents material to
pending litigation.  Thus, on November 12, Gilmore made an
ex parte application to file these documents under seal with
Judge Thelton Henderson, the federal judge hearing his case.
Gilmore also concurrently filed a motion for leave to amend
his original complaint in order to address the constitutional
and other issues arising from his possession of the documents
and the criminality of disseminating documents found in
libraries open to the general public.

It is important to realize that the criminal statute at issue
here does not recognize improper classification as a defense.
Under existing law, the government need only show that the
documents were classified by the government, and that they
are cryptologic- or communications-intelligence-related.  It
remains unclear precisely what the specific requirement
under the statute is, i.e., whether "knowingly" means actual
knowledge of classification, or merely some reason to know.

(That same day, NSA filed two motions of its own:
a motion for a protective order blocking Gilmore's discovery 
requests, and a motion for summary judgment asking the
court to dispose of the case on the ground that NSA was
entitled to judgment as a matter of law.  In support of its
summary judgment motion, NSA filed a sworn declaration
by Michael Smith, Chief of Policy, explaining why the
documents should be withheld, and why NSA's FOIA
processing procedures were not illegal.)

NSA was served with papers indicating that WF-3/4 had been
received by the district court.  This was the first time that
NSA knew that Gilmore possessed the documents.  They
reacted strongly.  John Martin, the Justice Department lawyer
representing NSA, asked that Gilmore surrender his copies to
NSA, saying that NSA was very upset and might send its own
agents or FBI agents to get the copies from Gilmore.  He also
wanted to know where Gilmore got them.  Martin also suggested
that Gilmore might be criminally liable under the espionage
statutes relating to possession of national defense information.

NSA regained its composure the next day, realizing that it
did not know exactly what Gilmore had.  Although NSA had
been served with papers indicating what Gilmore had done,
Gilmore had not sent them copies of the documents.  Thus
they could not know for sure whether the documents he had
were the ones they considered classified.  Gilmore agreed to
send copies of his copies to NSA for their review, after
which NSA would decide what to do.

During this period, tension was high.  Gilmore considered
filing an ex parte motion for a temporary restraining order
against NSA and the U.S. Attorney General to prevent them
from both moving against him personally and against any
copies of the documents presently on library shelves.  This
motion was drafted but never filed.

On the day before Thanksgiving, NSA announced that WF-3/4
would be declassified, and effectively renounced any claim
that it could withhold them from the public.  NSA gave no
official reason for its action.

NSA is currently reviewing the third document, LC-3, to
see how much of it can be released now that WF-3/4 have
been declassified.  (NSA had asserted in its summary judgment
papers that LC-3 was based on WF-3/4.)  NSA's review is to
be completed by January 15, 1993, at which time it will
release an edited version of LC-3 to Gilmore.

It is anticipated that this edited version of LC-3 will be
analyzed by Gilmore and his experts, and that Gilmore and
NSA will engage in settlement negotiations to determine
whether NSA has satisfied Gilmore's request.  The
settlement discussions will also include Gilmore's claims
regarding NSA's FOIA processing procedures.

The parties have stipulated that if no settlement is reached
the litigation will proceed.  A status conference has been
set for February 9.  NSA will, if necessary, file an amended
motion for summary judgment by February 12.  Following
opposition and reply briefs, the hearing on all motions will
take place on March 22.

[John Gilmore is a member of the EFF Board of Directors. He can
reached as gnu@cygnus.com.  Gilmore's lawyer, Lee Tien, can
be reached as tien@toad.com.]


                  -==--==--==-<>-==--==--==-


                THE CRYPTO ANARCHIST MANIFESTO

                              by
                        Timothy C. May
                      (tcmay@netcom.com)


A specter is haunting the modern world, the specter of crypto 
anarchy. 

Computer technology is on the verge of providing the ability for 
individuals and groups to communicate and interact with each other 
in a totally anonymous manner. Two persons may exchange 
messages, conduct business, and negotiate electronic contracts 
without ever knowing the True Name, or legal identity, of the other. 
Interactions over networks will be untraceable, via extensive re-
routing of encrypted packets and tamper-proof boxes which 
implement cryptographic protocols with nearly perfect assurance 
against any tampering. Reputations will be of central importance, far 
more important in dealings than even the credit ratings of today. 
These developments will alter completely the nature of government 
regulation, the ability to tax and control economic interactions, the 
ability to keep information secret, and will even alter the nature of 
trust and reputation.

The technology for this revolution--and it surely will be both a social 
and economic revolution--has existed in theory for the past decade. 
The methods are based upon public-key encryption, zero-knowledge 
interactive proof systems, and various software protocols for 
interaction, authentication, and verification. The focus has until now 
been on academic conferences in Europe and the U.S., conferences 
monitored closely by the National Security Agency. But only recently 
have computer networks and  personal computers attained sufficient 
speed to make the ideas practically realizable. And the next ten 
years will bring enough additional speed to make the ideas 
economically feasible and essentially unstoppable. High-speed 
networks, ISDN, tamper-proof boxes, smart cards, satellites,  Ku-band 
transmitters, multi-MIPS personal computers, and encryption chips 
now under development will be some of the enabling technologies. 

The State will of course try to slow or halt the spread of this 
technology, citing national security concerns, use of the technology 
by drug dealers and tax evaders, and fears of societal disintegration. 
Many of these concerns will be valid; crypto anarchy will allow 
national secrets to be traded freely and will allow illicit and stolen 
materials to be traded. An anonymous computerized market will 
even make possible abhorrent markets for assassinations and 
extortion. Various criminal and foreign elements will be active users 
of CryptoNet. But this will not halt the spread of crypto anarchy.

Just as the technology of printing altered and reduced the power of 
medieval guilds and the social power structure, so too will 
cryptologic methods fundamentally alter the nature of corporations 
and of government interference in economic transactions. Combined 
with emerging information markets, crypto anarchy will create a 
liquid market for any and all material which can be put into words 
and pictures. And just as a seemingly minor invention like barbed 
wire made possible the fencing-off of vast ranches and farms, thus 
altering forever the concepts of land and property rights in the 
frontier West, so too will the seemingly minor discovery out of an 
arcane branch of mathematics come to be the wire clippers which 
dismantle the barbed wire around intellectual property.

Arise, you have nothing to lose but your barbed wire fences!


                   -==--==--==-<>-==--==--==-


Date: Wed, 02 Dec 92 21:31:47 -0800
From: haynes@cats.UCSC.EDU (Jim Haynes)
Newsgroups: comp.dcom.telecom
Subject: Historical Note on Telecom Privacy

Apropos of all the talk on FBI wiretapping, cellular eavesdropping,
etc., I found this passage in "Old Wires and New Waves"; Alvin F.
Harlow; 1936.  He's writing about unscrupulous telegraph operators in
the early days.  They would use information in telegrams for personal
gain, or delay messages or news for personal gain, or sell news
reports to non-subscribers of the press association.

    "Pennsylvania passed a law in 1851, making telegrams secret,
    to prevent betrayal of private affairs by operators.  When,
    therefore, an operator was called into court in Philadelphia
    a little later, and ordered to produce certain telegrams which
    would prove an act of fraud, he refused to do so, saying that
    the state law forbade it.  The circuit court, shocked at this
    development, proceeded to override the law, saying:

       It must be apparent that, if we adopt this construction
       of the law, the telegraph may be used with the most
       absolute security for purposes destructive to the
       well-being of society - a state of things rendering
       its absolute usefulness at least questionable.  The
       correspondence of the traitor, the murderer, the robber
       and the swindler, by means of which their crimes and
       frauds could be the more readily accomplished and
       their detection and punishment avoided, would become
       things so sacred that they never could be accessible to
       the public justice, however deep might be the public interest
       involved in their production.
    
    The judge therefore ordered the operator to produce the telegrams."


                   -==--==--==-<>-==--==--==-


         THE SECOND ANNUAL INTERNATIONAL EFF PIONEER AWARDS:
                       CALL FOR NOMINATIONS
                     Deadline: December 31,1992

In every field of human endeavor,there are those dedicated to expanding
knowledge,freedom,efficiency and utility. Along the electronic frontier,
this is especially true. To recognize this,the Electronic Frontier
Foundation has established the Pioneer Awards for deserving individuals
and organizations.

The Pioneer Awards are international and nominations are open to all.

In March of 1992, the first EFF Pioneer Awards were given in Washington
D.C. The winners were: Douglas C. Engelbart of Fremont, California;
Robert Kahn of Reston, Virginia; Jim Warren of Woodside, California; Tom
Jennings of San Francisco, California; and Andrzej Smereczynski of
Warsaw, Poland.

The Second Annual Pioneer Awards will be given in San Francisco,
California at the 3rd Conference on Computers, Freedom, and Privacy
in March of 1993.

All valid nominations will be reviewed by a panel of impartial judges
chosen for their knowledge of computer-based communications and the
technical, legal, and social issues involved in networking.

There are no specific categories for the Pioneer Awards, but the
following guidelines apply:

   1) The nominees must have made a substantial contribution to the
      health, growth, accessibility, or freedom of computer-based
      communications.

   2) The contribution may be technical, social, economic or cultural.

   3) Nominations may be of individuals, systems, or organizations in
      the private or public sectors.

   4) Nominations are open to all, and you may nominate more than one
      recipient. You may nominate yourself or your organization.

   5) All nominations, to be valid, must contain your reasons, however
      brief, on why you are nominating the individual or organization,
      along with a means of contacting the nominee, and your own contact
      number. No anonymous nominations will be allowed.

   6) Every person or organization, with the single exception of EFF
      staff members, are eligible for Pioneer Awards.

   7) Persons or representatives of organizations receiving a Pioneer
      Award will be invited to attend the ceremony at the Foundation's
      expense.

You may nominate as many as you wish, but please use one form per
nomination. You may return the forms to us via email to

             pioneer@eff.org

You may mail them to us at:
             Pioneer Awards, EFF,
             155 Second Street
             Cambridge MA 02141.

You may FAX them to us at:
             +1 617 864 0866

Just tell us the name of the nominee, the phone number or email address
at which the nominee can be reached, and, most important, why you feel
the nominee deserves the award.  You may attach supporting
documentation.  Please include your own name, address, and phone number.

We're looking for the Pioneers of the Electronic Frontier that have made
and are making a difference. Thanks for helping us find them,

The Electronic Frontier Foundation

        -------EFF Pioneer Awards Nomination Form------

Please return to the Electronic Frontier Foundation
via email to:       pioneer@eff.org
via surface mail to EFF 155 Second Street, Cambridge, MA 02141 USA;
via FAX to +1 617 864 0866


Nominee:

Title:

Company/Organization:

Contact number or email address:

Reason for nomination:

Your name and contact information:

Extra documentation attached:

DEADLINE: ALL NOMINATIONS MUST BE RECEIVE BY THE ELECTRONIC FRONTIER
FOUNDATION BY MIDNIGHT, EASTERN STANDARD TIME U.S., DECEMBER 31,1992.


                   -==--==--==-<>-==--==--==-


         MEMBERSHIP IN THE ELECTRONIC FRONTIER FOUNDATION

If you support our goals and our work, you can show that support by
becoming a member now. Members receive our bi-weekly electronic
newsletter, EFFector Online, the @eff.org newsletter
and special releases and other notices on our activities.  But because
we believe that support should be freely given, you can receive these
things even if you do not elect to become a member.

Our memberships are $20.00 per year for students, $40.00 per year for
regular members.  You may, of course, donate more if you wish.

Our privacy policy: The Electronic Frontier Foundation will never, under
any circumstances, sell any part of its membership list.  We will, from
time to time, share this list with other non-profit organizations whose
work we determine to be in line with our goals. If you do not grant
explicit permission, we assume that you do not wish your membership
disclosed to any group for any reason.

---------------- EFF MEMBERSHIP FORM ---------------

Mail to: The Electronic Frontier Foundation, Inc.
    155 Second St. #40
    Cambridge, MA 02141

I wish to become a member of the EFF  I enclose:$__________
    $20.00 (student or low income membership)
    $40.00 (regular membership)
    $100.00(Corporate or company membership.
    This allows any organization to
    become a member of EFF. It allows
    such an organization, if it wishes
    to designate up to five individuals
    within the organization as members.)

    I enclose an additional donation of $

Name:

Organization:

Address:

City or Town:

State:     Zip:    Phone:(    )     (optional)

FAX:(    )    (optional)

Email address:

I enclose a check [  ]   .
Please charge my membership in the amount of $
to my Mastercard [  ]     Visa [  ]    American Express [ ]

Number:

Expiration date:

Signature:

Date:

I hereby grant permission to the EFF to share my name with
other non-profit groups from time to time as it deems
appropriate   [  ]  .
      Initials:

Your membership/donation is fully tax deductible.
=====================================================================
     EFFector Online is published by
     The Electronic Frontier Foundation
     155 Second Street, Cambridge MA 02141
     Phone: +1 617 864 0665 FAX: +1 617 864 0866
     Internet Address: eff@eff.org
 Reproduction of this publication in electronic media is encouraged.
 Signed articles do not necessarily represent the view of the EFF.
 To reproduce signed articles individually, please contact the authors
 for their express permission.
=====================================================================
     This newsletter is printed on 100% recycled electrons.

-- 
Rita Rouvalis                                Electronic Frontier Foundation
rita@eff.org                                                    eff@eff.org
CIS:70007,5621                                                (617)864-0665

--
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@soda.berkeley.edu
Date: Sat, 12 Dec 92 14:25:21 PST
To: cypherpunks@toad.com
Subject: no subject (file transmission)
Message-ID: <9212122224.AA04784@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks!

Like several people (I guess), I am working on an implementation of
digital cash.  Because of the possible legal repurcussions, I'd prefer
to remain anonymous at this time.  Thanks to the efforts of the people
on this list, this is now possible.

My implementation is pretty far along.  It uses PGP modules for the
arithmetic, so the speed is good.  It works on Unix and I should be
able to get it working on MSDOS in a day or two.  Sorry, I don't have
the ability to work on a Mac version.

Here are some of the features.  The basic cash algorithm is the Chaum
system which was posted here.  Multiple denominations are supported,
using different exponents for each denomination.  The program is
presented in the context of a package to be used for an email based
game like Monopoly where the program would be used to allow cash
transfers.  One player is the "banker", and he uses a different
execution module than the other players.  The banker program keeps a
database of used note numbers which is used to detect money reuse.
The database is maintained using a freeware version of the "dbm"
package, so it should be fast even for large note number databases.

The mapping between exponents and values is as follows:

    exponent	    value
	17		1
	19		2
	23		5
	29		10
	31		20
	37		50
	41		100
	43		200
	47		500
	53		1000
	59		2000
	61		5000
	67		10000

and so on, up to a value of 2e9.  The exponents are ascending primes
starting with 17.  This was chosen because you want them to be
smallish for fast note checking, but it was too slow to find primes p
and q for the bank key such that (p-1)(q-1) was not divisible by any
small primes.  The program chooses random p and then tests p-1 to make
sure it passes the divisibility test, and rejects it if not.  Too many
were being rejected when I started with an exponent of 3.  Starting
with 17 rejects about 1/2 the exponents, compared to something like
80% when I started with 3.  The "value" fields are presumed to be
cents, but could be whatever you like.

The code I've written does not do anything other than the basic
electronic cash algorithms.  It does not do bank account maintenance.
It doesn't do PGP encryption.  It doesn't send mail.  (It does have
some functions to scan and check the files created by the program.)

Cash generation is a 3 step process.  First, the user creates what I
call a "withdrawal request" packet.  This is a set of triplets of the
form (e, s, refx), where e is the exponent from the table above, s is
a 16-byte "unique identifier" used solely to link these withdrawal
requests with the returned messages from the bank, and refx is r^e * f(x).
f(x) is MD5 of x, padded to the size of the bank's modulus n using the
PGP routine which pads MD5 signatures.  This padding helps make sure the
arithmetic is more "mixing".  x is the random input to MD5, which I've
chosen as 64 bytes since that is the block size MD5 works on.  (The
output of MD5 is 16 bytes.)  r is the blinding factor.  This is now
128 bits long; longer r's take too long to calculate r^-1 in the third
step, below.  (It takes longer for PGP to calculate r^-1 than to do an
RSA decryption, for r = n = 1024 bits!)

Second, the bank program converts the withdrawal request packet into
what I call a "withdrawal" packet, by just RSA-decrypting the third
entry using the inverse exponent "d" for the value exponent "e".
(These "d" values are calculated at keygen time and stored with the
bank's key information in a private file.)  I call the return triplet
(e, s, rfxd), where e is the value exponent again, s is the same
unique identifier, and rfxd is r * f(x)^d.

(As I said above, the code I've written does not try to maintain
account balances or do any other banking functions.  It just does the
cash algorithms.  There is a routine to scan a withdrawal request and
return the total value being requested for withdrawal.  The idea was
that this could be used as input to a banking program to decide
whether to allow the withdrawal.)

Third, the "player" (e.g. user) program transforms the withdrawal
packet into a "money" packet, by un-blinding it.  To do this, it has
to recover the x and r which correspond with each triplet.  This is
done by the use of a dbm database of "pending withdrawal requests"
which is written during step 1, above.  The database entries are keyed
by (e, s) and return the corresponding (x, r) which were generated
during step 1.  Using x and r, the user transforms (e, s, rfxd) into
(e, x, fxd), the digital cash.  e is the value exponent, x is the
random 64-byte number, and fxd is f(x)^d, the signed version of the
MD5'd and padded x.

There are also player functions to scan and check a money file
(comparing a calculated f(x) to fxd^e), merge money files, and extract
some items from a money file into another money file (this last is
what is to be used for payment).  There are banker functions to check
incoming money and compare against the used-note database, and to add
incoming money to that database.  (The database consists of the
16-byte f(x) values for each note.)

I am pretty happy with the basic routines, but the user interface
needs work.  There are three kinds of files floating around
(withdrawal requests, withdrawals, and money files) and I'm worried
that this will be confusing to the user.  If he accidentally deletes
one at the wrong time he could lose money permanently.  Or if he
accidentally reuses one he could be accused of fraud.  I'm not sure
what the best model is for the user.

The specific issues of creating withdrawal messages and extracting
"bills" from a money file are areas where the user interface should be
made nice.  We want to make it easy for the user to specify exactly
what denominations he wants to work with.  One possibility is to
simply have him input the amount (e.g. $10.55) and the program
calculates that that's a 1000, a 50, and a 5, but this isn't really
flexible enough.  A nice system would be to give him a list of options
and let him fill out a form on-screen, but that's hard to do portably.

Another idea I've had is that there should be a special money file
called the user's "wallet" which is the default place where incoming
money from the bank should go.  This might help organize things.  He
still needs to be able to create other money files for paying other
people, and remembering to delete them after he sends them.

Any suggestions or thoughts on these interface issues, or comments
about how this program could or should be integrated into a larger
system, would be appreciated.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/
sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE
a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR
tAl4UGhhZWRydXM=
=HVRq
-----END PGP PUBLIC KEY BLOCK-----





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: nobody@rebma.rebma.mn.org
Date: Sat, 12 Dec 92 14:04:53 PST
To: cypherpunks@toad.com
Subject: no subject (file transmission)
Message-ID: <m0n0efX-0006XfC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Update on the digital cash project

I am having some problems with the port to MSDOS, mostly due to
implicitly assuming 32-bit integers in a few places.  Probably I won't
get it working until next weekend.

To recap, the program provides Chaum-style digital cash via two
executables, one for the "players" and one for the "banker".  The
banker creates a public key which has a single modulus n and multiple
exponents, the prime numbers starting with 17.  He sends n to the
players and all is ready.

Players withdraw money by running their programs and specifying the
denominations they want to withdraw.  For example, you could withdraw
a 1, two 5's, a 10 and a 20.  This would create a file with 5 entries
to be sent to the bank.  PGP should be used to encrypt and
ascii-encode this file (for privacy) and it should be mailed to the
banker.

The banker receives this file and runs his program to RSA-sign the
values in each of the withdrawal-request entries.  This is the
"blinded cash" that Chaum describes.  Again, PGP should be used for
mailing this back to the user.

The player then has to "unblind" the file to make it "real" digital
cash.  This also changes it so that the bank won't recognize it when
it is deposited.  He uses his version of the program to do this,
producing an actual digital money file with the five "digital bills"
in it.

To pay another user, he runs another function to extract the desired
bills from this file.  Suppose he wants to extract a 1 and a 5.  This
leaves a 5, a 10 and a 20 in the original file, and creates a new
digital cash file with a 1 and a 5.  He would then use PGP again to
encrypt this for safety and mail it to the person he wants to pay.

That person can run a "check" function on the incoming digital money
to make sure it has a proper bank signature on it and is not a
forgery.  He would then mail it directly to the bank so that it could
get credited to his account.

The banker runs his program which checks the signatures on the
incoming money, looks in a database file to make sure these bills
haven't been used before, and adds these bills to the database.  (The
database stores 16 bytes per bill.)  He should then record the deposit
and perhaps send a confirmation to the depositor (my program doesn't
get involved with that).

I hope this gives a clearer picture of how the electronic money
program works.  It is a simple implementation but I think many systems
would work similarly.

I appreciated the suggestion to use cash as part of the list
management itself.  Rather than paying people who post, I wonder if it
would be better to make people pay to post.  Many people have
complained about the volume.  :)  Unfortunately, I suspect that this
would involve too much overhead for the mailing list maintainer.

Maybe the thing to do is to just get the software out there and let
people decide what they want to do with it (if anything).  I'm
probably going to take a couple more weeks to clean up the user
interface and get these bugs out, then I'll try sending it someone to
be put on the cypherpunks ftp archive.

It's nice to be able to finally sign these messages!

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/
sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE
a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR
tAl4UGhhZWRydXM=
=HVRq
- -----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyZADQrkCJ6S8691AQHneQP8DRdkOFfG9TwjGDJAX4IxymvzAITqYIJC
aMhytyzqFwP6Dku955ZHEPL1SDpNCU8DwK7eKDOgvHRS3m+kihs1l6VR3Gf0AgGw
7jjRJlt7hcqfT16fLHVXtn27A16rUhl2hKrD702wjGzX+MN7mS/8MW2kchVfvQYX
M/McOuwuIjs=
=/HGX
-----END PGP SIGNATURE-----




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill O'Hanlon <wmo@rebma.rebma.mn.org>
Date: Sat, 12 Dec 92 15:44:58 PST
To: cypherpunks@toad.com
Subject: Remailer problem at rebma fixed
Message-ID: <m0n0g5G-0006bMC@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain



My apologies to those who have used PGP with the remailer at rebma
over the past week.  I upgraded to pgp2.1, and I failed to notice
that the PGPPASS environment variable has given way to the -z password
option.  Users of Hal's remailer scripts take notice.

I ran the mail through that had failed, so there might be duplicates
of messages sent out, since some people might have resent the message
if they didn't see it go by (that is, if they sent it to something where
they'd see the result, such as the cypherpunks list.)

Sorry for the inconvenience.

-Bill

-- 
Bill O'Hanlon						 wmo@rebma.mn.org



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 11:35:50 PST
To: cypherpunks@toad.com
Subject: dc-nets implementation (protocol spec)
Message-ID: <9212131931.AA13443@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


I am writing a dc-net implementation.   What follows is some design 
discussion, a protocol specification that defines the interaction,
message format, and file formats, followed by notes, and plans for
future enhancements.  A basic familiarity with the concept of dc-nets is
assumed, for people new to this, see Chaums's article on the topic,
posted here recently.

I am assuming interaction through e-mail because this is, right now,
the most accessible medium.  A more efficient approach would be to
use a true broadcast media, such as coax cable, or satellite.  But
coax only works for local areas, and not everyone has satellite uplink
capability.

In the future, I envision all or most local area networks running their
own small dc-nets that use ethernet broadcast, these being linked
hierarchically to medium-level dc-nets that use any internet type of
communication medium (udp datagrams, tcp connections, smtp, usenet news,
shared ftp space, etc) or other regional communication such as radio
(amateur packet radio, spread-spectrum, or even CB) , and these finally
being linked into global dc-nets that use satellite broadcast.  

This type of system would achieve the truly anonymous global communication
system, similar to what Vinge describes in True Names:

      He dumped the last twenty-four hours of the world bulletin
      board into his home memory space and began checking through
      it.  The bulletin board was ideal for untraceable reception
      of messages: anyone on Earth could leave a message [...] If 
      a user copied the entire board, and /then/ searched it, there
      was no outside record of exactly what information he was
      interested in.  There were also simple ways to make nearly 
      untraceable entries on the board.

DC-nets will remove the "nearly" from the last sentence.

The system I am writing is for research purposes only, I would like to 
have about 6 to 8 people running it, and then observe it in action. 
I am not aware of any existing, operational dc-net.  If you know of
one, please let me know.  I would not like to develop a new, incompatible
protocol if it is not fundamentally better than something existing.

The dc-net system is independent of how the keys are distributed/created.
This system assumes that there is already a key stream existing between
any two users, that it can use.

There are several methods by which keys can be distributed.  The most
secure would probably be to use a hardware RNG to generate a one-time
pad, which is then trasfered by some secure means (exchanged on floppies
in person, or put on a 4GB DAT tape (4mm, $20 or less) and sent by
some courier service, etc).  Another possibility is to use
Diffie-Hellman protocol to agree on a set of keys.  The simplest method,
and one I chose to use in this project, is to generate a random key
stream, encrypt it with the other person's public key, sign it with
yours, and send it through e-mail.  See the next message for details
on message formats used for this.  

Again, the core dc-net system described in this message is in no way
dependent on this form of key exchange.  Any other key distribution
method can be "dropped in" without changing anything.

The design document follows:


--------------------------------------------------------------------------
ALGORITHM (pseudocode):

This algorithm is executed independently by each participant.  The list
of participants, RBSIZE, and MSGSIZE must be agreed on beforehand.  There
must be an existing keystream, or a way to receive one.

Begin Round (increment round number)

Stage 1 (reservation):
    Take RBSIZE bits off everyone's pad, xor all together.
    For every message you need to send, reverse a random bit.
    Sign with your public key, and transmit to all.
    When received everyone's block, xor all together.
    If result is all zeros, round ends.  Go on to the next round.

Stage 2 (transmission):
    For every '1' bit in reservation block:

    Begin Message (increment message number)

        Take MSGSIZE bits off everyone's pad, xor all together.
        If the bit was reserved by you, xor with your message.
        Sign with your public key, transmit to all.
        When received everyone's block, xor all together, getting message.
        If message was yours, verify it, mark it as sent.
        If not, it is a message from someone else. Process as an incoming
	message.

    End Message (go to next set bit of reservation block if any)

End Round (go to next round, optionally delay to save bandwidth)



----------------------------------------------------------------------------
MESSAGE FORMAT:

(messages are sent as signed, armored, non-encrypted PGP messages)

 Subject: dc-net transmission

 DCNET <network>; ROUND <round>; PARTICIPANT <userid>; STAGE <stage> [MSG <n>]

 <binary data stream follows>

----------------------------------------------------------------------------
FILE FORMATS:

dcnet/<netname>/myname

    your own participant name for that network


dcnet/<netname>/participants       

    list of participants and addresses in the following format:

         <userid>:<address>


dcnet/<netname>/pad/<participant>

    one-time pad for the user, straight 8-bit binary data
        optionally pgp-encrypted with your public key, signed to prevent
        disclosure and tampering; these options not implemented yet


dcnet/<netname>/spool/<stage>/<participant>

        spool where you store responses received, until you receive
        all of them.  Your own responses are stored there too


dcnet/<netname>/outgoing/*

        messages you need to send, one message per file.  
        should be stored encrypted too. 


dcnet/<netname>/incoming

        program that will process any messages received from this 
        network.  In the simplest case this would be a shell script
        that puts the message to the user's mailbox.  But it could
        also drop it into another net's outgoing directory if it
        matches some criteria, or it could be posted to a newsgroup,
        or anything else you want to do.


dcnet/<netname>/log

        this file contains log of transmissions received times and sizes.
        it should only contain public information, so it can be posted
        for analysis of net efficiency, bandwidth used, etc.


------------------------------------------------------------------------
NOTES:

I must thank the ILF (Information Liberation Front) for their timely post
of Chaum's article.  I had started with the two-person example provided
in the cypherpunks glossary, and independently extended it to apply to
any number of participants, and had progressed up to the idea of
hierarchial dc-nets, and was struggling with the question of collision
detection, when the article was posted.  Chaum's reservation blocks are
an elegant and efficient solution.  His formal proof of security is
also reassuring.

RBSIZE is the number of bits in the reservation block.  This should be
much larger than number of participants, to minimize the chance of
two participants randomly reserving the same bit (in which case the
transmission has to be retried in the next round).  A convenient number
to use is 1024 bites (128bytes), if the number of users is small.

When operating in idle mode (no messages to be sent), RBSIZE bits are
sent to each participant each round. So the total bandwidth used is,
assuming 1kbit RBSIZE, 25 participants, and two rounds an hour, about
150 kilobytes per day sent and received by each participant, or about 14
bits per second.  This is quite insignificant, considering today's 
communication equipment.  

MSGSIZE is the size of a message.  This should be about the size of an
average message, not the largest one.  Making this too large will waste
bandwidth.  I will use message size of 5kilobytes.  This is quite
small, but enough for research purposes.  This will make the messages
several screenfuls long.  Longer messages can be split into parts, and
reassembled.  For example, this message would be split into two parts.

For each message that is sent, the number of bytes that every every
participant must send and receive is MSGSIZE times the number of 
participants (using the above assumptions, 125 kilobytes).

Using a true broadcast media would dramatically reduce these bandwidth
requirements, making large-scale systems with many participants
feasible.

This implementation uses a <netname> to distinguish between separate
dc-nets a user may be participating in.  A netname can be any string, 
subject to filename limitations.  Keeping them alphanumeric and under 14
chars should work on most machines.. They might also be case insensitive.

Netnames do not have to be globally unique, one person just can not be on
two nets of the same name.

Persons are referenced to by <participant>, which would normally be the
username but can be an arbitrary string subject to the same limitations.
Two perople with the same participand name can not be on one dc-net.

Are any of you amateur radio (HAM) operators?  I would be interested if
this system could be run over packet radio.  Are there any regulations
against encrypted traffic?  

----------------------------------------------------------------------
FUTURE ENHANCEMENTS:

In addition to mail-based interaction, usenet newsgroups, ethernet broadcasts,
shared ftp access, and tcp connections should be supported.  

A protocol for dynamically adding participants to the net, removing
oneself from the net, or changing the address should exist.

A way to deal with malfunctions, such as not receiving a message from
a participant.  Currently the net will wait forever, for that one message
to arrive.  A time-out should probably established, after which everyone
will re-send their contribution without including the missing person.
This is potentially dangerous, since it is equivalent to disclosing that
participant's key streams.  Since one-time pad is used, this will not
compromise earlier communication, but the person must be notified if they
ever come back on-line to not use that portion of key again.

Support for encrypted and signed storage of keystreams and outgoing
messages. 

A protocol for routing messages between hierarchical dc-nets.

Automatic splitting of messages longer than MSGSIZE.

A way to indicate the message size in the allocation block, so
communications would not be wasted on small messages, and large messages
would not have to be split into pieces.

-----------------------------------------------------------------------
PLEASE send any comments, criticism, or ideas to:

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Sun, 13 Dec 92 15:48:50 PST
To: uunet!tree.egr.uh.edu!barrus@uunet.UU.NET
Subject: Electronic P.O.Boxes
In-Reply-To: <9212132255.AA13304@tree.egr.uh.edu>
Message-ID: <9212132330.AA04018@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


The new remailers will support pseudonymous return addresses, but
they're not ready yet.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Sun, 13 Dec 92 14:56:08 PST
To: hpengwyn@cix.compulink.co.uk
Subject: Electronic P.O.Boxes
In-Reply-To: <memo.806675@cix.compulink.co.uk>
Message-ID: <9212132255.AA13304@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



John,
	Thanks for the comments.  Right now (as far as I know) the
only way to be able to receive "anonymous replies" is for you to
include in your message the appropriate header.  This is the method I
use: create the necessary remailing request to your real mail address,
and include that with the instructions on how to use it.  For example:

----here is a sample letter----
Hello,
	This is an anonymous letter and you don't know who I am.  To
reply, cut everything below the marks, add your text on the end, and
send the whole thing to this address: <a remailer's address>

-----cut here-----
::
Encrypted: PGP

<here is where you would put your encrypted remailing request to your
real mail address...>

<Enter your text here, below the "END PGP" block that will delimit the
remailing request.  Mail the portion between the cut marks to the
appropriate remailer.>
----cut here----
----end of the sample letter----

It works! 

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sun, 13 Dec 92 18:29:13 PST
To: cypherpunks@toad.com
Subject: Re: Random numbers (and big primes, too!)
In-Reply-To: <9212131408.AA00292@britt>
Message-ID: <9212140227.AA04427@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



David Clunie writes:

> It would seem to me that someone somewhere should produce a "random
> number server" available via a well-known internet port number. Some
> natural phenomenon not readily available to all could be used to generate
> such numbers and one could just connect and ask for a number. It would be
> interesting to try to devise means by which interception or sequencing
> could be prevented.

Announcing a New Service: "Primes 'r Us"

Your full-service crypto dealer.

-specializing in selling large primes to those gullible enough to use
them
-discounts for really big primes!
-we can sell you random numbers, too...and we promise not to tell what
you bought!

Now you can be spared the hassle of generating primes for your RSA
algorithms. Now you can let "someone else do the driving."

Better yet, Primes 'r Us can handle all your cryptographic
needs...we'll generate your primes, computer your keys, and supply
your random numbers!


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 15:42:04 PST
To: cypherpunks@toad.com
Subject: one-time-pad distribution for dc-nets
Message-ID: <9212132337.AA20132@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


As mentioned in my previous message, dc-nets need a one-time pad keystream.
Of the many methods of accomplishing this, for my experimental dc-net I
chose not the most secure method, but the simplest to implement.
Recognizing that dc-net users will want to use various key-distribution
mechanisms (true one-time pad, with the keys trasnfered over a secure
out-of-band channel, diffey-hellmann, etc) I designed the dc-net to be as
independent of the key distribution method as possible.  The dc-net just
reads the keystream from a file, and calls a program when it is about to
run out of keys, and needs more.  

This message describes the method of key distribution I will use.  I assume
that all participants know each others' public keys, and have verified such
by independent means, or they are signed by mutually trusted certifiers.
PGP encryption is used to send randomly generated one-time pad.  Two
participants send keys to each other whenever the remaining key stream 
reaches below an agreed-upon threshold, then the keys are combined in a
pre-determined way (no matter which one sent his message first, the result
will be the same).  Keys are transferred in large chunks, larger than the
normal message size, so that these trasfers would not have to be too
frequent.  

-----------------------------------------------------------------------
MESSAGE FORMAT:

(messages are sent as signed, armored encrypted PGP messages)

  Subject: dc-net transmission

  DCNET <network>; PARTICIPANT <userid>; KEYCHUNK <n>

  <binary data follows>


-----------------------------------------------------------------------
ALGORITHM:

When remaining keystream for <userid> on dcnet <network> falls below
MINTHRESHOLD, increment keychunk number (n), generate CHUNKSIZE random
bits, encrypt and sign them, and send them to the other person.

Wait for the other participant's message.  Decrypt it, and verify the
signature. 

Compare the two key chunks (the one you sent, and the one you received),
and order them by placing the one with lower value first.

Append them in the above order to the key file.


------------------------------------------------------------------------
NOTES:

If both persons use the same MINTHRESHOLD and CHUNKSIZE, then they should
send their messages at approximately the same time, but there is no
guarantee of which one will arrive first.  If a keychunk is received before
one has been sent, one is generated and sent, and then compared to the
received key.

For the sake of simplicity, I will assume everyone will use the same
CHUNKSIZE and MINTHRESHOLD.  This is not a requirement, and the proper
operation of the system in now way depends on this.

The purpose of MINTHRESHOLD is to provide a safety margin, so that key
exchange would not interfere with the regular operation of the dc-net.

In choosing CHUNKSIZE and MINTHRESHOLD, the basic tradeoff is space versus
time.  Maximizing these values will reduce the number of transmissions,
possibly making more efficient bulk transmission methods possible.  But, it
will increase the storage requirements of each participant.

Each participant will need to store at most

(MINTHRESHOLD+CHUNKSIZE) * <number of participants>

Each participant will need to obtain new keys approximately every 

RBSIZE/CHUNKSIZE of idle rounds, or MSGSIZE/CHUNKSIZE of messages
transmitted.

For this project I will choose a CHUNKSIZE of 75K, allowing for 600 idle
rounds, or 15 messages transmitted.

MINTHRESHOLD will be 150K.  The storage requirements will be about
2 megabytes of a net of 8 participants, or about 5 megabytes for a net
of 25 participants.



----------------------------------------------------------------------
FUTURE ENCHANCEMENTS:

A more efficient bulk-transfer method may be used, such as dropping the
chunks off to a known ftp site.  As soon as the chunk is picked up, it is
deleted.  Many ftp sites have such "temporary", "incoming", or "dropoff"
directories.  Many sites could be agreed on, in case one fails.  All
participants should not use the same site, so as not to cause too much load
on any single machine.

Some method of randomizing the key transfer could be used, so all
participants would not run out of keys at the same time, causing
unneccessary load on the mail transport system.

If a broadcast medium is used, an efficient variant of Diffey-Hellmann
can be used, in which each participant needs to generate only one secret
random number, and publish the corresponding public value.  Then every one
can combine it with their secret value, in a way that results in each pair
of participants having a common secret key unknown to anyone else.

If feasible, one-time-pads can be transferred in person, using floppy
disks.


--------------------------------------------------------------------
Again, I would appreciate any ideas, comments, suggestions at:


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 16:18:58 PST
To: cypherpunks@toad.com
Subject: Yes they exist (re: Electronic P.O.Boxes)
Message-ID: <9212140014.AA21225@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


Such systems do exist.  I have info on one handy, but I know at least
one other based on the same software exists in finland.  

This one seems to be still using pgp2.0, I don't know when they will 
upgrade to pgp2.1.

These remailers assign you a pseudony like anon.19, and anyone can
send mail to anon.19@pax.tpa.com.au and the mail will be forwarded
to you.


Here's the file you can get by sending an empty message
to anon.info@pax.tpa.com.au.

 PAX - Public Access Unix (Adelaide,South Australia) - Anonymous Posting Host
 ============================================================================

Last modified: Fri Nov 20 18:55:52 CST 1992

 Information about Anonymous & Privacy-Enhanced Posting.
 =======================================================

PAX is conducting research into the viability of anonymous privacy-
enhanced mail as a means of providing practical, secure and confidential
electronic mail and news. An experimental server has been setup and
you are encouraged to use it.

There are many anonymous posting services in existence which provide
anonymous electronic mail and posting to specific newsgroups where
posting is sometimes harmful to one's health or reputation ! Such
services allow you to:

 - post anonymously to those news groups

 - reply anonymously to posts by email

 - converse anonymously with another anonymous user, neither of
   you knowing your real identities

Privacy-enhanced electronic mail refers to the concept of encrypting
one's mail prior to sending it off into the ether, presumably to
someone at the other end capable of decrypting it. If one uses a
so-called "public key" method of encryption, then one can make one's
"public" key widely known so that anyone can encrypt mail to you, but only
you can decrypt it using your "secret" key. There is much development
going on in this area, but one quite popular public-domain implementation
is Philip Zimmermann's "Pretty Good Privacy 2.0" which makes use of a
number of cryptographic methods including the RSA algorithm in places
(See Legal Issues later on). PGP allows you to:

 - exchange public keys with another individual

 - encode messages to them that only they can read

 - receive messages from them that only you can read

These tools are all very well for the specific purposes for which they
were designed, but unfortunately your anonymous message or post is not
actually anonymous until it gets to the machine that host's the service.
Anyone in between, including your own administrators, can in theory
read your post, even though they won't know to whom it is directed. What
is more they can also read replies addressed back to you. This can be
highly embarrassing at best, and result in dismissal or disconnection
at worst if your thoughts, beliefs or activities are disapproved of by
the powers that be, even if they are perfectly legal.

PAX's privacy-enhanced anonymous services were conceived in the belief
that free speech and privacy are fundamental rights and that it is
high time the networks to which we are connected provided such services
on a routine basis. Seeing as they don't we have to make a start somewhere.

This service provides:

 - conventional anonymous mailing and posting services via a "normal"
   alias assigned in the usual fashion

 - the ability to post to ANY newsgroup that is carried out of PAX
   (which includes most non-regional groups)

 - PGP 2.0 based privacy-enhanced mail & posting, including:

   - ability to register your "public" key with PAX, so that PAX
     can send encrypted messages to you

   - local generation of a unique public key which is sent to you,
     so that you can send encrypted messages to PAX

   - any encoded messages from you mailed to a user or newsgroup are
     decrypted at PAX before being passed on in anonymous form

   - any anonymous replies to your "pgp" alias are encrypted before
     being mailed to you

For example, once you have obtained your PGP 2.0 software (as described
later) and got it going, and once you have generated and registered
your public key and received PAX's key in response, you will be able
to post to any newsgroup without anyone beyond your machine having
access to the plaintext of your post.

Furthermore, if another user has registered in the same manner, and
you know their anonymous alias or are responding to one of their
anonymous posts, even though you don't know who they are and haven't
exchanged keys to communicate directly, the PAX service will automatically
decrypt any encrypted messages from you and re-encrypt them before
passing them on to the other person !

 How to use it.
 ==============

All transactions are handled by email, and commands are selected by
the name of the alias to which you mail, not by the subject or body
of the message (which are ignored unless sending or posting a message).
The separator between the "anon" and the command is a dot (period,'.')
and nothing else will work ! Not '-', not '_', not ":", only a dot.

The site to address mail is "pax.tpa.com.au". If this fails for some
reason, you may need to address it to the specific host (at present)
ie. "flash.pax.tpa.com.au".

"Normal" (unencrypted) commands:

 - To get information (this message):

    mail anon.info@pax.tpa.com.au

 - To see what your "normal" alias is, or get one:

    mail anon.ping@pax.tpa.com.au

 - To send a reply to another anonymous user:

    mail anon.###@pax.tpa.com.au

    NB:
      - eg. mail anon.36@pax.tpa.com.au

      - don't be creative ... anon.036 won't work

      - an attempt is made to strip off signature lines by discarding
        everything after a line starting with "--" or "__"

 - To send a post to a newsgroup:

    mail anon.post.groupname@pax.tpa.com.au

    NB:
      - eg. "mail anon.post.talk.abortion" will send a
        post to "talk.abortion"

      - only the Subject field from your post is used, the rest of
        the header is discarded

      - the newsgroup is selected by the alias; Newsgroup header
        fields are discarded; hence cross-posting isn't feasible

      - signatures are stripped as above

"PGP" (encryption) commands:

 - To register your public key with PAX: (ABSOLUTELY NECESSARY)

    mail anon.key@pax.tpa.com.au

    NB:
      - first you have to make install pgp and make a key then send it
        in a "anon.key" command

      - the body of the message MUST contain an ascii encoded public key
        generated by PGP V2.0. You may use your regular public key that
        you give to other people if you wish. The user ID name must be
        unlikely to conflict with one PAX already has, so use your full
        name, or include your email address or something. If you want
        you can use a unique key just for PAX - it makes no difference.
        If PAX already has a key of the same user-id it will reject yours.
        Note that this means that you need different key user-id's on
        different machines (or mail addresses anyway).

        # makes new keys & adds to your "keyring"
        pgp -kg
        Enter a user ID for your public key: First M. Last of somefirm

        # extract key in ascii form suitable for a message body
        pgp -kxa "First M. Last of somefirm" savedfile pubring

        # send it to PAX
        mail anon.key@pax.tpa.com.au <savedfile.asc

      - PAX will respond by sending you a new alias number and a
        public key to add to your keyring to use to encrypt messages
        to PAX. It will have a user ID name of "paxanon.publickey"
        and you should add it to your public key ring by saving the
        message in a file and presenting it as follows:

        pgp -ka savedfile

        Your life will be easier in future if you reply yes to the
        certify question.

      - Note that now you may have two aliases, that sent in response to
        the anon.key command and that sent in response to the anon.ping
        command or previous unencrypted replies or posts. Any sunsequent
        replies or posts that you encrypt before sending will be seen
        to others as having come from the new alias, and replies will be
        encrypted before being passed on to you. Any plaintext messages
        you send will appear to have come from the original alias and
        responses will also come back in plaintext.

 - Sending encrypted posts and replies.

     There are no other commands. If you encrypt a message and send it
     using the "anon.reply" and "anon.post" groups, the software will
     detect that they are encrypted, select the appropriate alias as
     a return address, decrypt the message, and mail or post it.

     You should use PGP 2.0 to encrypt messages sent to PAX, using
     the public key that PAX sent to you. DON'T FORGET TO SIGN your
     message using the secret key corresponding to the public key
     that you sent to PAX !!! Unsigned messages will be rejected
     to ensure that the message is really from you and not someone
     pretending to be you using your account or mailpath.

     Eg.:

        # sign and encrypt message for mailing to pax.
        pgp -east message "paxanon.publickey" -u "First M. Last of somefirm"
        mail -s "A test post" anon.post.alt.test <message.asc

     Note the -a (armor) and -t (text) options. Note also the subject
     flag to mail - PAX will whinge if you post something without a
     subject.

     Similarly, all messages to you will be signed using PAX's secret
     key corresponding to the public key PAX sent to you, hence you
     will know if the message really came from PAX and not someone
     else using your public key.

     ***** NB. The ENTIRE encrypted segment will be passed on after
     it has been decrypted. There is no processing of any contained
     header (though it won't work as a header), nor any removal of
     signature information within the encrypted text. Take great care
     to ensure that there is no identifying information within the
     encrypted text. *****

     Any plain text accompanying the encrypted text will be discarded.
     The Subject header field is still passed on during postings as
     with "normal" unencrypted posts.

     More work may be done on these "features" if there is sufficient
     demand for it :).

Miscellaneous administrative commands:

 - To see the current status of the system (message of the day):

    mail anon.status@pax.tpa.com.au

 - To send mail to a human administrator:

    mail anon.admin@pax.tpa.com.au

 Mailing List
 ============

To send mail to/join/unjoin a mailing list about this service, and
anonymous services in general:

    mail anon.list@pax.tpa.com.au
    mail anon.subscribe@pax.tpa.com.au
    mail anon.unsubscribe@pax.tpa.com.au


 How secure is it ?
 ==================

Not bad. Clearly it depends on the security of the underlying PGP 2.0
software which is discussed at length in its documentation.

The keys are stored, and the messages encrypted and decrypted on
a server which also hosts a Public Access Unix system. These files
are protected by the usual Unix security mechanisms, but in the
event of a security breach could conceivably become visible. The
keys would hence be compromised and any messages passing through
could be decrypted. The PAX administration could theoretically
access the keys and files at will of course.

It is hard to conceive of an alternative implementation which links
anonymity with privacy enhancement however. This is no substitute for
a direct person to person link with certified keys and this service
should not be used as a substitute for such if security is a primary
concern.

 Legal Issues.
 =============

PGP 2.0's use of the RSA algorithm is a problem in the US where a patent
is now held on the algorithm, despite its widespread promulgation before
the patent was obtained. The PGP documentation discusses this issue at
length.

Sufficeth to say, this service is provided by a site in Australia and
hence should not be subject to the constraints imposed by the US patent.
The service is offered to anyone who can reach this site by mail, in
addition to PAX's own users, and there is no intention of obtaining any
commercial gain by providing the privacy-enhanced anonymous service.

Whether individuals in the US can legally use the PGP software to use the
service provided by PAX for their own personal use, without first obtaining
a license to use the RSA algorithm is an untested issue. Certainly the
software is widely available even though it is now maintained outside the
US.

No such concerns should apply anywhere other than the US.

This project is an experiment to see if the concept is feasible and if
there is any demand for it. The software is crude, but functional,
but it is quite possible that it will fail in unforeseen circumstances.
It is designed to loose or fail to pass on a message rather than post or
return plaintext (which would be very undesirable) but there can be no
guarantees. It is conceivable that plaintext might get sent where it
was not intended, and PAX assumes no responsibility for the consequences.
At least this would be no worse than the situation that prevails with
current anonymous services.

THIS IS EXPERIMENTAL SOFTWARE IN A STATE OF FLUX - YOU HAVE BEEN WARNED.

END OF FILE

--
** Anonymity & Privacy by PAX - Public Access Unix (Adelaide,South Australia) **

anon.admin@pax.tpa.com.au (a human)    anon.info@pax.tpa.com.au   (for help)
anon.ping@pax.tpa.com.au  (get alias)  anon.key@pax.tpa.com.au    (register key)
anon.###@pax.tpa.com.au   (reply)      anon.post.g@pax.tpa.com.au (post to g)
anon.list@pax.tpa.com.au  (to mailing list)
anon.subscribe@pax.tpa.com.au          anon.unsubscribe@pax.tpa.com.au

For dialup Unix access phone +61-8-235-9010 - online registration.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: John Styles <hpengwyn@cix.compulink.co.uk>
Date: Sun, 13 Dec 92 11:52:18 PST
To: cypherpunks@toad.com
Subject: Electronic P.O.Boxes
Message-ID: <memo.806675@cix.compulink.co.uk>
MIME-Version: 1.0
Content-Type: text/plain



Do any of the remailer schemes proposed address the problem of the ability
to have replies sent to you without the replier knowing to whom they
are replying - this being akin to P.O.Boxes / Magazine box numbers and
equivalents.
A sample use might be.
I wish to send someone a message so I request a box from someone
e.g.
---
mail to someone@somewhere
AllocateBoxTo:hpengwyn@cix.compulink.co.uk
---
This would send a code to you identifying a unique box and allowing you to
identify yourself (presumably you would want the ability to send this reply
by remailer so you are not identifying yourself to the box holder). It would
also send a code to you for you to pass on to repliers to your message.

You would then post and/or send the message to the person/people you wished
to communicate with (this need not be from the same account) passing on the
second of these two codes and an address to send messages to (this would
presumably be the box holding company unless you wanted the replier not to kno-
w
who was running the box, as well as not knowing who it is for).

They would reply by sending this code and a message to the address given 
(possibly anonymously of course).
This message (probably encrypted) would be held for you - allowing you to
receive messages from accounts not even set up at the time you requested
the box.

You would then get the replies by sending a message
e.g.
---
mail to someone@somewhere
GetReplies
<text of FIRST code sent by box holder>
<address or some mechanism for replies to find you>
---

Maybe the scheme discussed previously can do all of this (except the ability
to have accounts set up after replies have been sent to you) if so please
explain how. [I have only recently joined the list]

Thanks,
John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 16:39:37 PST
To: dclunie@pax.tpa.com.AU  (David Clunie)
Subject: Re: Random numbers
In-Reply-To: <9212131408.AA00292@britt>
Message-ID: <9212140035.AA21752@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> It would seem to me that someone somewhere should produce a "random
> number server" available via a well-known internet port number. Some
> natural phenomenon not readily available to all could be used to generate
> such numbers and one could just connect and ask for a number. It would be

I would not trust someone to generate random numbers for me.  For all
you know, they may be recording the date, time, and who is requesting
the number, and selling the information to the highest bidder (guess who?).







From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sun, 13 Dec 92 17:04:43 PST
To: cypherpunks@toad.com
Subject: ps -laxww for randmoness?
Message-ID: <9212140100.AA22531@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


How about using ps -laxww as a source of randomness?  Of course it would be
run throug something like MD5 to get rid of the structure.  This would
not be good on a multi-user system because ps command may have been 
modified to log the person invoking it, time, and output to somewhere.

But on a personal workstation that you trust, it could be a pretty
good source of unpredictable data.

This is not my original idea, I think it was suggested in one of the
multiple precision math packages I looked at recently.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wcs@anchor.ho.att.com
Date: Sun, 13 Dec 92 19:08:48 PST
To: cypherpunks@toad.com
Subject: Re: Random numbers (and big primes, too!)
Message-ID: <9212140308.AA00536@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text



Timothy May writes:
> Announcing a New Service: "Primes 'r Us"
> Your full-service crypto dealer.
> -specializing in selling large primes to those gullible enough to use them

Actually, I may decide to talk my wife into running such a service. 
It will have at least one customer (me), and any more who want to buy primes
or key pairs, given the level of trust we can provide (moderate, but...).

Why, you ask?  Well, she's about to buy a new computer for her business,
as well as personal use, and the amount you can depreciate or expense depends
on the percentage of time you've used the machine for business.
Calculating primes can take a *large* percentage of your idle time,
and what matters for tax purposes are the percentages and whether you do or
don't make a profit for the year, not *which* activities of the same business
are profitable...
			Signed, Pat Pending

P.S. Yeah, I know, now that I've told you guys the secret, the bottom will
drop out of the market because you can generate primes faster on your Cray
than we can on a 386.  Sigh....





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Sun, 13 Dec 92 22:51:01 PST
To: cypherpunks@toad.com
Subject: A minor experimental result
Message-ID: <9212140649.AA12228@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



One of the purposes of setting up remailers is to experiment with
them, see what kind of emergent behavior appears, see what kind of
flaws and obstacles arise, see how they break, etc.

Here's one: the compromise of my "anonymity" by one of the folks
running a remailer. (Who and where don't matter, just the phenomenon
itself.)

I used a single bounce without any encryption to send a message and
got a query from the owner of the remailer saying "I couldn't help
looking through my remailer archives and noticing...." and requesting
more information from me!!

Hoist by my own petard!

Several lessons:

* Multiple bounces help, even without encryption, as then the remailer
sysop can't be sure who originated the message.

* Encryption is of course even more desirable, though a hassle
(especially for Mac users).

* Remailer sysops should make a point to _not_ look at their remailer
archives. In fact, they should discard them immediately (for their own
legal protection, and for slightly greater trust amongst users, though
this is a hazy area...).

(Recall that the "mix" on which our software-based remailers are
loosely patterned are "memoryless," i.e., the tamper-resistant modules
that implement the receive-decrypt-store-forward protocol have no
memory of the mapping between incoming and outgoing messages. In
fact, the outside world cannot possibly compromise the protocols to get
at this information.)  

So, my laziness in using only a single bounce, combined with the
curiosity of a remailer sysop, breaks the anonymity.

Neither surprising nor profound, but I thought you folks would like to know.


--Tim May

--
..........................................................................
Timothy C. May | Crypto Anarchy: encryption, digital money,
tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
408-688-5409 | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sun, 13 Dec 92 20:43:46 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: dcnets...
Message-ID: <921214043710_74076.1041_DHJ56-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

I thought I would reply here to Yanek's message about dc-nets
since it is a topic that should be of interest to the list.

I think it's great that someone is going to start experimenting
with these systems.  The sooner we start playing with this technology,
the better.

I have a few general comments about the system.  First, I like the
idea of splitting the key information management from the communication
management.  That way people can choose their level of security, all
the way up to one-time pads if they want.

However, I think there should be another system chosen for exchanging
key information initially than using PGP to send large one-time pads.
Dc-nets really eat up the bandwidth.  Yanek estimates using 125
kb per message sent!  And having to send one-time key information
around doubles the bandwidth.

Also, Eric Hughes pointed out to me in private mail once that a system
like this for key information exchange is only computationally secure.
You are basically relying on RSA and IDEA not to be broken.  As long
as you're doing that for this initial experiment, why not save yourself
a lot of trouble.  Just exchange an IDEA (or DES) seed, then cycle it
repeatedly through IDEA (or DES), taking the low order bit or few bits
as new random ones.  If two people have the same seed, they will generate
the same random bits.  And if IDEA is secure, your bits should be
secure.  If they aren't, PGP isn't secure.  PGP has code to do this.
I think it's in the IDEA.C module.  Also see strong_pseudorandom in
CRYPTO.C.

So, I'd suggest that the key exchange part just exchange a short key
and then a program generates the new random bits as needed for the
messaging.  Keep the key stuff separate, though, so people really can
do one-time pads if they want to eventually.

Another point is the amount of messaging people will do.  I think the
system should be enhanced to allow people to send and receive messages
to/from non-DC-net participants.  Otherwise you have 10 or 20 people
who hardly know each other.  What will they have to say to each other?
You won't get a good picture of message loads.

I don't foresee everybody in the world being hooked into interlocking
DC-nets any time soon (if ever).  But I do think there will be DC-nets
for some interested people.  They will achieve anonymity amongst
the group for messages sent beyond the group.  In other words, it will
be known that a message comes from a certain DC-net group, but it will
be impossible to tell which person in the group sent it.  Likewise,
messages could be sent to a DC-net group without it being known to whom
they are sent.

I think this capability should be added very soon to the DC-net software.
It sounds like the software may include automatic message-sending capability
and if so, something which just recognized a special message header and
took it as "Request-Remailing-To:" should be easy to add.  Likewise,
incoming messages to the Dc-net (which would be sent to some random
person in the group) should be easily forwardable to the DC-net system
from outside.  I don't have a clear picture of the user interface from
Yanek's description so I'm not sure how easy/hard these would be to do.

One other thing I'd mention: the mechanism of reserving a slot and then
sending a message is discussed at some length in the Ph.D. thesis of
Jurgen Bos.  Tim May kindly sent me an excerpt from the thesis which
included this discussion; I think it may have been part of the original
cypherpunk meeting handout.  Bos compares several message reservation
schemes and discusses which are the best.  It might be good for Yanek
to take a look at this document.

Yanek asks about sending encrypted traffic over amateur bands.  This
is definately illegal in the U.S.  The reason is that the amateur bands
can't be used for commercial purposes, so the FCC demands to be able
to know everything that is being sent to make sure this rule is being
complied with.  However, there are some commercial packet-radio systems
starting up and presumably they won't be subject to this limitation.

It may not be practical to incorporate all of these suggestions at first,
but I do think that using PGP to exchange a RNG seed would be better
than using it to exchange one-time pads.  I'm looking forward to seeing
the system in operation.

Hal
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyvk8qgTA69YIUw3AQHyuQP/fXIkyCWR5GCiZsiRvMThcJK5xMbOQEIF
ow9S9xQ+7kiiJuF4dVp7NRyNTBjO2tBiQDh4JRKb4Pl7LGq+KKYQSTDzGgEo7hOw
dkgujwxbCAXjn2XEMewRHprZMPV4XB+iGIZzQ4piqubzWg8hOV8sMhduGaHKnhGc
MlhbbmhToOc=
=+cPN
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dclunie@pax.tpa.com.AU (David Clunie)
Date: Sun, 13 Dec 92 16:09:59 PST
To: cypherpunks@toad.com
Subject: Re: Random numbers
Message-ID: <9212131408.AA00292@britt>
MIME-Version: 1.0
Content-Type: text/plain


>     It has lately been discussed different ways to construct pure
> random number generators by means of radiactive decay. I must admit
> that this is a very good way to produce such numbers, but for a
> number of reasons it is impractical to use such a device. (High
> radiation levels are needed too produce a significant amount of data.)
> 

It would seem to me that someone somewhere should produce a "random
number server" available via a well-known internet port number. Some
natural phenomenon not readily available to all could be used to generate
such numbers and one could just connect and ask for a number. It would be
interesting to try to devise means by which interception or sequencing
could be prevented.

david




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dclunie@pax.tpa.com.AU (David Clunie)
Date: Sun, 13 Dec 92 16:10:48 PST
To: cypherpunks@toad.com
Subject: Re: Paranoia and Cypherpunks
Message-ID: <9212131419.AA00298@britt>
MIME-Version: 1.0
Content-Type: text/plain


> 
> Headline: "CIA chief hints change needed in ban on probing Americans"
> 
> Excerpts:
>  	WASHINGTON--CIA Director Robert Gates says changes might be  
> needed in the U.S. law that forbids the agency from collecting  
> information about Americans or U.S. companies.
> 	Such changes might enable the CIA to better support the  
> Justice Department and other law enforcement agencies, he said in an  
> interview with the Associated Press.

Juding by what I read in "The Puzzle Palace" the other day, I gather no
such ban exists on the NSA doing this. Hardly seems to matter much
whether one has two "Big Brothers" watching over use or just one !
And the budget of the NSA is a hell of a lot bigger than the CIA.

david




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "DrZaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Mon, 14 Dec 92 10:31:47 PST
To: cypherpunks@toad.com
Subject: A Quote for the List
Message-ID: <19576.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


     Here's a quote I snagged off an h/p bbs... thought it was particularly
true of cipher-technology as well as computing in general.

>>>
As life moves to this electronic frontier, politicians and corporations are
starting to exert increasing control over the new digital realm, policing
information highways with growing strictness. Before we even realise we're
there, we may find ourselves boxed into a digital ghetto, denied simple
rights of access, while corporations and government agencies make out their
territory and roam free. So who will oppose the big guys? Who's going to
stand up for our digital civil liberties? Who has the techno-literacy
necessary to ask a few pertinent questions about what's going down in
cyberspace? Perhaps the people who have been living there the longest might
have a few answers.

-Mark Bennett
<<< TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Liam David Gray <lg2g+@andrew.cmu.edu>
Date: Mon, 14 Dec 92 10:32:18 PST
To: cypherpunks@toad.com
Subject: Re: A minor experimental result
In-Reply-To: <9212140649.AA12228@netcom.netcom.com>
Message-ID: <4f=97Zm00Uh7Q1WlJ_@andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain


Excerpts from Cypherpunks: 13-Dec-92 A minor experimental result by
Timothy C. May@netcom.com:
>  
> * Multiple bounces help, even without encryption, as then the remailer
> sysop can't be sure who originated the message.
>  

Tim,

    Please tell me if this makes sense:

    If I wanted to be obnoxious, I could set myself up as a remailer,
then screen all incoming messages to see whether they came from other
known remailers.  If not, then I can archive the message, have a look at
it, and maybe compromise the original sender.

    Is this so?

    In this case, everyone wanting to use a remailer should in principle
*own* a remailer, and you'd probably want your own to be the first
remailer.  Then, to avoid compromise of the recipient, maybe you'd want
yours to be the last remailer.  So why not use your own remailer
exclusively?

    To take this to an extreme, set up a remailer and then use this
*all* the time for the mail you originate.  Does this gain you anything?

    Just curious.  I'm new on the list and might be missing something. 
Thanks in advance for replies from anyone.

Liam Gray








From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Mon, 14 Dec 92 10:31:18 PST
To: 74076.1041@CompuServe.COM (Hal)
Subject: Re: dcnets...
In-Reply-To: <921214043710_74076.1041_DHJ56-1@CompuServe.COM>
Message-ID: <9212141634.AA01103@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain



> I have a few general comments about the system.  First, I like the
> idea of splitting the key information management from the communication
> management.  That way people can choose their level of security, all
> the way up to one-time pads if they want.

I tried to make the system as modular as possible, so any part could be
improved or changed with minimal effects on the rest of the system.
 
> Dc-nets really eat up the bandwidth.  Yanek estimates using 125
> kb per message sent!  And having to send one-time key information

This is due to two factors.  First, right now there is no way to specify
the size of a message.  Every message is assumed to be 5K so bandwidth is
wasted for any message smaller than that.  As I mentioned in "FUTURE 
ENHANCEMENTS" section, I will make message size be part of the reservation
block structure, so small messages will be transferred more efficiently.

Second, I am using point-to-point transmission.  When I want to broadcast
a message, I need to send it individually to each participant.  Use of
a broadcast media such as ethernet multicast or satellite or radio will
dramatically decrease communications load.  

> as you're doing that for this initial experiment, why not save yourself
> a lot of trouble.  Just exchange an IDEA (or DES) seed, then cycle it
> repeatedly through IDEA (or DES), taking the low order bit or few bits

This is a good idea.  I will do it this way unless anyone else can
see any problems with this.
 
> Another point is the amount of messaging people will do.  I think the
> system should be enhanced to allow people to send and receive messages
> to/from non-DC-net participants.  

If a broadcast system could be used, anyone that can receive the broadcast
will be able to reconstruct the messages, even if they are not participating
in the net.  If this project works successfully, I will try it using usenet
as the medium.  So anyone can scan alt.dcnets and get the message.

> and if so, something which just recognized a special message header and
> took it as "Request-Remailing-To:" should be easy to add.  Likewise,

Yes it is easy to add.  Eventually you will be able to request forwarding
to a mail address (or a mix-net remailer), an anonymous post to a usenet
newsgroup, or retransmission to another dc-net.

The only small problem is that everyone gets the message, and I don't want
the message sent out 15 times.  So there must be some way to decide who
does the remailing.  I could just have one person act as the forwarder,
but it would be more interesting (and harder to break) if the net somehow
dynamically assigned a random forwarder for each message.

> incoming messages to the Dc-net (which would be sent to some random
> person in the group) should be easily forwardable to the DC-net system

Yes.  Mix-net remailers could also be participants in a dc-net, so a
message could be sent without anyone even knowing which remailer it
came from, for people that want untraceability but don't want to or can't
participate in a net themselves.

> from outside.  I don't have a clear picture of the user interface from
> Yanek's description so I'm not sure how easy/hard these would be to do.

Very easy.  To send out a message on a dc-net you just drop it into it's
outgoing directory, the next round it gets transmitted.  

Any messages received are piped to "incoming" program in that dcnet's 
directory.  That program initially will just put the message in your
mailbox, but you can make it do anything, such as drop it in another
dc-net's incoming directory, or remail it, or post it somewhere.

 
> One other thing I'd mention: the mechanism of reserving a slot and then
> sending a message is discussed at some length in the Ph.D. thesis of
> Jurgen Bos.  Tim May kindly sent me an excerpt from the thesis which
> included this discussion; I think it may have been part of the original
> cypherpunk meeting handout.

Can someone forward it to me?

> Yanek asks about sending encrypted traffic over amateur bands.  This
> is definately illegal in the U.S.  The reason is that the amateur bands
> can't be used for commercial purposes, so the FCC demands to be able
> to know everything that is being sent to make sure this rule is being

But the messages become public.  Anyone can see what the message is, they
just can't see who it came from.  If all messages are transmitted as
plaintext, it is fairly easy to see that no commercial traffic is occurring.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Mon, 14 Dec 92 10:31:00 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Remailers.
Message-ID: <921214165323_74076.1041_DHJ77-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


Tim's message brings up a point I've been wanting to mention.
The prototype remailer software keeps log files of all messages
passed through it.  There are different reasons why people running
the software might wish to have these logs.  One purpose is for
debugging; the remailers don't produce much in the way of error
messages and the log files can be useful for tracking down errors.

A few weeks ago, for example, one user was having difficulty sending
messages through my remailer, and he posted here about it.  I was
able to confirm that his messages had come in and been sent out.

However, another possible reason is for the case of abusive messages.
I had one message go through that appeared to be directed towards
the sender's boss, and was rather unfriendly in tone.  The remailers
give the outgoing messages the superficial appearance of having
come from me.  This message wasn't that bad, but there's nothing
to stop someone from sending a really vicious, racially or sexually
harrassing message, and I am very concerned that I could get in
trouble for that.

What I've generally done is to delete the log files every few
days, usually after a quick perusal to see if there are any
messages which the recipient might object to.  Sometimes if I see
a message which is of an illegal format so that it didn't get sent,
(like forgetting the ":" in "Request-Remailing-To:") I'll send a
message to the sender telling him what he did wrong.

I feel that people who run remailers should set their own policies
as far as the confidentiality of the messages they forward.  Running
a remailer can be somewhat risky in the current climate and the
operators can legitimately seek whatever level of protection they
are comfortable with.  However, I think it would be good if the users
of the remailers could get some information about what the privacy
policies are.  Maybe some remailers will simply not keep logs; maybe
others will keep logs but not look at them unless a specific circumstance
arises, and so on.  Eric Hollander has been creating a list of remailers;
perhaps he could solicit this kind of information from the operators
and publish it along with the remailer addresses and keys.

Hal
74076.1041@compuserve.com


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eli Brandt <ebrandt@jarthur.Claremont.EDU>
Date: Mon, 14 Dec 92 13:18:36 PST
To: cypherpunks@toad.com
Subject: Re: Remailers.
In-Reply-To: <921214165323_74076.1041_DHJ77-1@CompuServe.COM>
Message-ID: <9212142118.AA03045@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> Eric Hollander has been creating a list of remailers;
> perhaps he could solicit this kind of information from the operators
> and publish it along with the remailer addresses and keys.

(Hey, everybody send your remailer information in!)

I have been deleting the logs every so often, unread since I debugged
the remailer.  If someone asks me if their message made it, I'll look
at them.  If someone gives me evidence of blackmail or the like, I'll
look at them.  Otherwise, to the bit bucket they go.

As usual, you should encrypt your message if you want it to be secure.
This is a multi-user system.  Furthermore, I may read the remail logs
from time to time as I tweak the software.  (eg add PGP, if I can fix
the "keygen error"...)

It may be worth pointing out that this gives me a plausible reason to
stonewall if someone comes asking about something *I* sent through my
remailer.

> Hal

   Eli   ebrandt@jarthur.claremont.edu




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: andrew_derry@sfu.ca
Date: Mon, 14 Dec 92 13:48:53 PST
To: cypherpunks@toad.com
Subject: Re: A minor experimental result
Message-ID: <9212142148.AA13622@whistler.sfu.ca>
MIME-Version: 1.0
Content-Type: text/plain


>    If I wanted to be obnoxious, I could set myself up as a remailer,
>then screen all incoming messages to see whether they came from other
>known remailers.  If not, then I can archive the message, have a look at
>it, and maybe compromise the original sender.
>
>    Is this so?

Seems quite possible to me..  I think that's why it was suggested a while
back that as many remailers be set up as possible.  That way, one could use
several in a row and virtually eliminate the problem.

>    In this case, everyone wanting to use a remailer should in principle
>*own* a remailer, and you'd probably want your own to be the first
>remailer.  Then, to avoid compromise of the recipient, maybe you'd want
>yours to be the last remailer.  So why not use your own remailer
>exclusively?

I don't think you'd have to worry much about compromising the recipient, if
you encrypt the message with with her public key (except possibly traffic
analysis, which I doubt poses a problem to very many people, and which can
be overcome anyways).

>    To take this to an extreme, set up a remailer and then use this
>*all* the time for the mail you originate.  Does this gain you anything?

Well, it would probably be ok if a lot of other people used your remailer..
but if you were the only one, I doubt it would be very effective.
---
Andrew Derry - derry@sfu.ca       |
ACS@HCC - Simon Fraser University |
Standard disclaimers apply        |





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Mon, 14 Dec 92 15:43:24 PST
To: yanek@novavax.nova.edu
Subject: ps -laxww for randmoness?
In-Reply-To: <9212140100.AA22531@novavax.nova.edu>
Message-ID: <9212141856.AA13053@maggie.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


>From: yanek@novavax.nova.edu (Yanek Martinson)

>How about using ps -laxww as a source of randomness?

Its a rather bad source. Operations of a computer system are
suprisingly low on entropy. I'd guess that, if I needed to and had
enough resources, I could break such a generator without more than a
few months work, and even get the system to break it semi-automatic.

No one here seems to think in terms of cryptanalysis and how people do
it when they come up with their schemes.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Mon, 14 Dec 92 15:50:57 PST
To: Eli Brandt <ebrandt@jarthur.claremont.edu>
Subject: Re: Remailers.
In-Reply-To: <9212142118.AA03045@toad.com>
Message-ID: <9212142349.AA29938@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



Since it is possible to archive, I think we should all operate under the
assumption that archiving is being done.  And if we are operating under that
assumption, there is nothing wrong with archiving.  This is why multiple,
encrypted, and possibly overseases boucnes are so important.  The security
of remailing doesn't depend on trusting the operators.  It relies on there
being at least one operator who won't reveal show his logs.  If one of your
bounces happens to be through your own remailer, you can gaurantee this.

e





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Mon, 14 Dec 92 13:18:54 PST
To: cypherpunks@toad.com
Subject: MEETING: 2nd Cypherpunks UK
Message-ID: <6405@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


[I thought a month's notice on this (second) meeting would draw a little
 more interest.  Our first meeting, 13 December 92, was a good start.
  -- Russell   ;-)  ]

2nd Meeting, Cypherpunks UK
---------------------------

Chris Tame, of FOREST and the Libertarian Alliance, has generously
offered the use of the meeting room at his offices for our gathering,
Sunday, 10 January 1993, from 1300 onwards, at:

  FOREST
  4th Floor
  2 Grosvenor Gardens
  London   SW1W 0DH
  071-823-6550

This is just around the corner from Victoria Station, at the end of the
mansion block near Hobart Place.  There's a dark green cabbie shelter
across the street from the entrance, and some British Telecom payphones.
Can't miss it, really.  However, if you have trouble, call the telephone
number above, or call my pager, on 081-812-2661.

If it helps, we're in the direction of Buckingham Palace, which is
(very) partially visible from our windows.

If you wish to attend, you should bring a 3.5" DOS-formatted diskette
(sorry!  My UN*X machine is an Intergraph workstation, and I can't use
it for crypto) with a copy of your PGP 2.0+ public key.  I'll sign it
there.  Mac users: if you don't have Apple File Exchange (what!?), I'll
be extra nice and take your keys anyway ( ;-)) for AFE conversion on my
IIcx.  Not to fear.

It might not be a bad idea to copy your public key on each of several
diskettes, so you've got a copy to distribute to each of the others.
Don't trust me to copy *your* key to others!  As a matter of fact, as
there are plenty of power points in the meeting room, you should bring your
laptop, and/or a desktop PC:  when someone hands you a disk-with-key,
you can sign her key, and hand her back her diskette, with your own
pubkey added.

[Note to the novice: don't hand another person your secret key... the
 one named secring.pgp.]

This should be a lively meeting.  Among the topics likely to be
discussed are:

  o   The proliferation of PGP public keys in the U.K.
  o   The local development of anonymous remailers and a proposed
        automatic public key repository at Demon Internet Systems
  o   Electronic networking/email security for the novice
  o   Pro-active proliferation of PGP 2.1+ to interesting European,
        African, and Asian sites
        -  ftp placement
        -  BBS distribution
        -  sneakernet across borders
  o   The use of HPACK in securing local file installations

.. and much more!

Mark Turner, from Demon Internet Systems, is likely to be on hand to
demo DIS for non-DIS users.  We've set up our own local, high-quality
newsgroups:
         demon.security
         demon.security.keys

and established the /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding
recently to include all versions of PGP, and "fellow traveller" files).

Hope to see you there!

Semper vigilans,
Semper vigilans,




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Mon, 14 Dec 92 13:55:56 PST
To: cypherpunks@toad.com
Subject: Re: A minor experimental result
In-Reply-To: <9212140649.AA12228@netcom.netcom.com>
Message-ID: <1992Dec14.211716.13061@extropia.wimsey.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain


lg2g+@andrew.cmu.edu (Liam David Gray) writes:

>    If I wanted to be obnoxious, I could set myself up as a remailer,
>then screen all incoming messages to see whether they came from other
>known remailers.  If not, then I can archive the message, have a look at
>it, and maybe compromise the original sender.

This is possible only if encryption is not used.  With encryption,
only the first remailer knows the sender (but not the plaintext or
recipient) and only the last remailer knows the recipient (but
not the sender or plaintext).
-- 
	Miron Cuperman <miron@extropia.wimsey.com>  | NeXTmail/mime ok
		       <miron@cs.sfu.ca>	    | Public key avail
	AMIX: MCuperman				    |
cybercomputingimmortallaissezfaire		    |




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Date: Mon, 14 Dec 92 19:04:59 PST
To: cypherpunks@toad.com
Subject: Re: Remailers.
Message-ID: <9212150304.AA06890@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> It relies on there being at least one operator who won't reveal
> his logs.  If one of your bounces happens to be through your own
> remailer, you can guarantee this.

Let's be clear on exactly how useful it is to route your messages
through your own remailer.  It's not as useful as it first appears.

If the Awful Nasties convince all of the remailers downstream of yours
to give up their logs, they trace the message back to your machine.
You then might choose to say, "Hey man, it wasn't my message, it was
just my remailer.  And I'm not giving you the logs."

But if you're going to use this excuse, you needn't really have routed
your message through your remailer at all; you just need to be operating
a remailer and routinely refuse to divulge its logs.


-- Marc Ringuette (mnr@cs.cmu.edu)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 15 Dec 92 07:56:18 PST
To: avalon@coombs.anu.edu.au
Subject: Re: ps -laxww for randmoness?timeofday for randmoness
In-Reply-To: <9212151530.AA05832@coombs.anu.edu.au>
Message-ID: <9212151555.AA10507@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> 	gettimeofday(&tv, NULL);
> 	rand = tv.tv_usec + tv.tv_sec;

Someone trying to break your code could find out approximately when
the number was generated, then they would have a much smaller search
space to try.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Karl L. Barrus <barrus@tree.egr.uh.edu>
Date: Tue, 15 Dec 92 09:43:54 PST
To: cypherpunks@toad.com
Subject: remailer extension (contact field)
Message-ID: <9212151743.AA20003@tree.egr.uh.edu>
MIME-Version: 1.0
Content-Type: text/plain



I've added a contact field to my remailer.  To contact me (the
operator of remailer03 <elee7h5@rosebud.ee.uh.edu>) you can use the
following header:

----cut here----
::
Contact:

----cut here----

Note the colon after contact and the blank line at the end.
Encryption of this header is supported as well; you can reach me by
encrypting this contact header and doing the usual.

For those interested - here are the changes to maildelivery and
remail.pl (I haven't been able to study the remailer code much, and am
just learning perl, so this can probably be improved.)

Changes to maildelivery, before the * on the last line
Add the following: (I spaced everything out in the file)

Contact  ""  pipe R  remail.pl
Contact  ""  file A  archive.remail

Add to remail.pl, before the block that begins
                  if (/^Request-Remailing-To:/ || /^Anon-To:/)

if (/^Contact:/) {
  chop ;
  s/^.*// ;
  $addressee = $_ ;
  $addressee = "my.id@some.other.machine" ;
}

I don't know perl well enough to figure out what can or can't be
deleted (specifically the $addressee = $_ line, etc.)

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/








From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Tue, 15 Dec 92 20:14:52 PST
To: cypherpunks@toad.com
Subject: Inf0
Message-ID: <9211157244.AA724460817@jplpost.jpl.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain


          Does anyone know of companies that will sell Tempest
          shielding to a private citizen, and if so; what regulations
          and licensing are required to own this equipment.

          Thanks in advance,

          JPW
          -----------------------------------------------------------
          JPL: 03-90 - 12-31-92.  Goldin + Peace + Politics = Layoff
          Anyone out there looking for an AA?
          -----------------------------------------------------------




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ahawks@nyx.cs.du.edu (zoiks!)
Date: Tue, 15 Dec 92 15:58:07 PST
To: cypherpunks@toad.com
Subject: subscribe
Message-ID: <9212152358.AA16200@nyx.cs.du.edu>
MIME-Version: 1.0
Content-Type: text/plain


Please subscribe me to the list...Heard about it from alt.cp, Mondo,
Paco Xander Nathan, and my own FutureCulture list...
-- 

    ahawks@nyx.cs.du.edu	        FutureCulture:  In/f0rmation
    ahawks@mindvox.phantom.com		future-request@nyx.cs.du.edu





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Date: Tue, 15 Dec 92 23:15:59 PST
To: avalon@coombs.anu.edu.au
Subject: Re: ps -laxww for randmoness?
In-Reply-To: <9212151530.AA05832@coombs.anu.edu.au>
Message-ID: <9212160715.AA09133@tsx-11.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


   From: avalon@coombs.anu.edu.au (Darren Reed)
   Date: Wed, 16 Dec 92 2:30:49 EST

   Has anyone tried using the microsecond counter from unix as a random
   source ?  Its obviously *not* going to be good if you want a continuous
   stream of random numbers, but if you need them just 'every now and then',
   what about it ?

This should be in an FAQ:  Unixes have different levels of granularity
in the microsecond counter; some systems may only have a 10 ms (that's
10000 microsecond) resolution to their clock.  So you can't necessarily
depend on a getting lot of bits of randomness from this method.

						- Ted




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: avalon@coombs.anu.edu.au (Darren Reed)
Date: Tue, 15 Dec 92 07:31:35 PST
To: cypherpunks@toad.com
Subject: Re: ps -laxww for randmoness?
In-Reply-To: <9212141856.AA13053@maggie.shearson.com>
Message-ID: <9212151530.AA05832@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


In some email I received from Perry E. Metzger, Sie wrote:
> 
> 
> >From: yanek@novavax.nova.edu (Yanek Martinson)
> 
> >How about using ps -laxww as a source of randomness?
> 
> Its a rather bad source. Operations of a computer system are
> suprisingly low on entropy. I'd guess that, if I needed to and had
> enough resources, I could break such a generator without more than a
> few months work, and even get the system to break it semi-automatic.
>
> No one here seems to think in terms of cryptanalysis and how people do
> it when they come up with their schemes.

Well whenever I try to come up with some nifty crypto scheme, I always
seem to think it is too easy to break if you know its being used but then
I dont like doing too much 'expensive' crypting and I usually find some
cheap algo which uses a more expensive one for key trading.

Has anyone tried using the microsecond counter from unix as a random
source ?  Its obviously *not* going to be good if you want a continuous
stream of random numbers, but if you need them just 'every now and then',
what about it ?

Something like this would be used:

	struct	timeval	tv;
	long	rand;
	...
	gettimeofday(&tv, NULL);
	rand = tv.tv_usec + tv.tv_sec;
	...

Very unlikely to get a duplicate, esp. if you dont need the number
more often than 1 per second.

darren




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Tue, 15 Dec 92 23:46:40 PST
To: tytso@ATHENA.MIT.EDU
Subject: re: ps -laxww for randmoness?
In-Reply-To: <9212160715.AA09133@tsx-11.MIT.EDU>
Message-ID: <9212160740.AA04597@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


Don Davis, of MIT Project Athena, did some research a number of years
back on getting good (physical) randomness out of a unix workstation.
If I recall correctly, the general idea was to look for trends and
biases, find explanations for them, and then filter them out or
normalize against them. Sources of "real" nondeterminism came from
things like variations in hard drive behavior (such as actual seek
time, which shows up indirectly in the paging system because it does
or does not cause time delays due to missed sectors...) I don't have a
reference handy, but if noone comes up with one I'll send him email
and see if he has it online.
	In other words, 'ps -laxww' itself is relatively useless --
but the underlying data does actually have randomness; you may have to
dig pretty hard for it, though.
							_Mark_

   SUB: Re: ps -laxww for randmoness?
   SUM: <tytso>, tytso (Theodore Ts'o)->avalon@coombs.anu.edu.au, cypherpunks@toad.com

      From: avalon@coombs.anu.edu.au (Darren Reed)
      Date: Wed, 16 Dec 92 2:30:49 EST

      Has anyone tried using the microsecond counter from unix as a random
      source ?  Its obviously *not* going to be good if you want a continuous
      stream of random numbers, but if you need them just 'every now and then',
      what about it ?

   This should be in an FAQ:  Unixes have different levels of granularity
   in the microsecond counter; some systems may only have a 10 ms (that's
   10000 microsecond) resolution to their clock.  So you can't necessarily
   depend on a getting lot of bits of randomness from this method.

						   - Ted





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: avalon@coombs.anu.edu.au (Darren Reed)
Date: Tue, 15 Dec 92 09:05:15 PST
To: yanek@novavax.nova.edu (Yanek Martinson)
Subject: Re: timeofday for randomnessness ?
In-Reply-To: <9212151555.AA10507@novavax.nova.edu>
Message-ID: <9212151704.AA15303@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


In some email I received from Yanek Martinson, Sie wrote:
> 
> > 	gettimeofday(&tv, NULL);
> > 	rand = tv.tv_usec + tv.tv_sec;
> 
> Someone trying to break your code could find out approximately when
> the number was generated, then they would have a much smaller search
> space to try.

Thats why you change key 'regularly'...even randomly ?

Then they have to 'guess' when you change keys.  It might be easy
to tell when an application starts, but how can you tell exactly or
even approximately how long ago someone picked a menu that changed
their key or it was otherwise changed ?

By using the microsecound counted as a random number, its almost
completely random unless you take steps to actually make less so.
But a table of the required million entries and 'init' strings
wouldn't be too hard for todays computers, hence the use of the
time in seconds to 'bump' the offset a bit.

For example, if you use a simple xor table for encoding/decoding,
its pretty easy to decode.  If you change the table after it has
been used, every time, then the required time to break the entire
message is significantly larger than it would otherwise have been.

Can anyone do some maths on exactly how long it would take given
a fixed table size (contains random data) ?  And also with key/
table changes at a fixed/random interval ?
(seems 1:1 :( but I maybe wrong).

darren




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: strat@intercon.com (Bob Stratton)
Date: Wed, 16 Dec 92 01:44:48 PST
To: wendtj@jplpost.jpl.nasa.gov
Subject: Inf0
In-Reply-To: <9211157244.AA724460817@jplpost.jpl.nasa.gov>
Message-ID: <9212160945.AA16858@intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


>>>>> wendtj@jplpost.jpl.nasa.gov (Jeffrey P Wendt) writes:

	Jeffrey>           Does anyone know of companies that will
	Jeffrey> sell Tempest shielding to a private citizen, and if
	Jeffrey> so; what regulations and licensing are required to
	Jeffrey> own this equipment.

I believe that InterPact, a company operated by Winn Schwartau that
also publishes the "Security Insider Report", does this type of work,

They're in Houston, I think.

--strat





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: treason@gnu.ai.mit.edu
Date: Wed, 16 Dec 92 07:34:13 PST
To: cypherpunks@toad.com
Subject: remailers
Message-ID: <9212161534.AA18300@spiff.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


   Does anyone have a ongoing list of remailers addresses and functions that
they could send me?  I haven't had time to compile a list myself, but would
appreciate itt greatly if I could get one.

Treason



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Wed, 16 Dec 92 11:48:04 PST
To: treason@gnu.ai.mit.edu
Subject: Re:  tempest devices and use
Message-ID: <9212161918.AA03733@servo>
MIME-Version: 1.0
Content-Type: text/plain


>It is illegal to use any device as a tempest shield, including lead, 
>tesla coils or any other materials that can possibly interfere with tempest
>reception!  You need a government license to use these, and then you must have 
>reason to have such a device(this is how banks can use such things.)

Eh? The specific purpose of TEMPESTing a computer that handles
classified information is to contain any incidental information-
bearing electromagnetic emissions so they cannot be received at a
distance. But shielding is not only a security issue, it is also
highly desirable to minimize interference to users of the radio
spectrum (e.g., broadcast TV sets and radios).

Now the FCC Part 15 rules (which govern "incidental radiation devices"
such as computers) are much less stringent than TEMPEST, but this is
only an economic tradeoff because full TEMPEST-level shielding of a
computer can be very expensive. In fact, many classified shops have
instead built "screen rooms" (or entire screened buildings, such as
those at the NSA) so they can use standard commercial-grade computer
hardware. Anyone is free to add as much shielding to their computer
equipment or their entire buildings as they want.  There's absolutely
nothing illegal about it; in fact it's highly commendable to do so.
The FCC (and your neighbors) will thank you for it.

Now if you wanted to "mask" your computer's RF emanations with some
sort of RF noise source (such as a Tesla coil) that's another story.
Most transmitters require licenses for the obvious reason that they
can interfere with other users of the radio spectrum. But this has
nothing to do with your right (or even duty) to shield your computers.

Unfortunately the TEMPEST rules themselves are classified, so we
really don't know how much shielding is necessary, or what one can
pick up from an unshielded system, or exactly how you'd do it.
Obviously this is an attempt to protect NSA's own SIGINT methods. But
there is, to coin a phrase, "equal protection under the laws of
physics".  Star Warriors' claims notwithstanding, they're the same
for everyone, black (classified) or white, and they're open for
all to discover and apply on their own.

Phil








From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: treason@gnu.ai.mit.edu
Date: Wed, 16 Dec 92 08:46:30 PST
To: cypherpunks@toad.com
Subject: remailers
Message-ID: <9212161646.AA18468@spiff.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


I don't know if this message got through, but I'll repost  it just in case...

What I would like is a list of remailers with maybe a description of the
fucntions(non-standard mail) like pgp abilities or whatever.  A list of
remailers would be good in itself.

treason




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: treason@gnu.ai.mit.edu
Date: Wed, 16 Dec 92 10:18:50 PST
To: cypherpunks@toad.com
Subject: tempest devices and use
Message-ID: <9212161818.AA18643@spiff.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


     For those who are interested in tempest devices and such...

It is currently legal to create/buy and use tempest devices for any citizen
under any circumstances.  It is also legal to sell such devices, with the exception of selling to non US citizens and governments.  This is the good news.

The bad news is:

It is illegal to use any device as a tempest shield, including lead, 
tesla coils or any other materials that can possibly interfere with tempest
reception!  You need a government license to use these, and then you must have 
reason to have such a device(this is how banks can use such things.)

I have a few tempests, one with a range of about 200 yards using aricraft
vdo's.  If anyone wants a file discussing the legal issues of the tempest,
please ask, and I'll forward it here.

treason@gnu



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Wed, 16 Dec 92 11:16:00 PST
To: treason@gnu.ai.mit.edu
Subject: Re: tempest devices and use
Message-ID: <9212161854.AA08014@maggie.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain



> From: treason@gnu.ai.mit.edu
> 
>      For those who are interested in tempest devices and such...
> 
> It is currently legal to create/buy and use tempest devices for any citizen
> under any circumstances.  It is also legal to sell such devices, with the 
> exception of selling to non US citizens and governments.  This is the good 
> news.
> 
> The bad news is:
> 
> It is illegal to use any device as a tempest shield, including lead, 
> tesla coils or any other materials that can possibly interfere with tempest
> reception!  You need a government license to use these, and then you must have 
> reason to have such a device(this is how banks can use such things.)
> 
> I have a few tempests, one with a range of about 200 yards using aricraft
> vdo's.  If anyone wants a file discussing the legal issues of the tempest,
> please ask, and I'll forward it here.

This particular bit of garbage is so malodorous that it can't be left
unchallenged. There are no rules saying that you can't shield your computer
equipment; in fact, there are FCC rules that say that you HAVE to shield
it, though you aren't required to do as well as tempest specs, which, to
my knowledge, are not even public knowledge.

Put up or shut up, Mr. "Treason". Give us one lick of evidence that you know
what you are talking about.

Perry





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: treason@gnu.ai.mit.edu
Date: Wed, 16 Dec 92 12:44:26 PST
To: cypherpunks@toad.com
Subject: tempest file
Message-ID: <9212162044.AA19398@spiff.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


I don't know what is in the file entirely, but it looked like the one I have
read on the legality of using tempest shields and such.  I have other files on the issue as well, I would like you guys to tell me whats you think, and if I 
should post the others as well.

treason@gnu   - You have free will, but you will go to hell if you use it!




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: treason@gnu.ai.mit.edu
Date: Wed, 16 Dec 92 16:26:15 PST
To: cypherpunks@toad.com
Subject: files
Message-ID: <9212170026.AA20674@spiff.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


   Of course half the problems with realistic discussions are aroused
by idiots flaming without checking their sources....

treason



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 16 Dec 92 17:34:17 PST
To: cypherpunks@toad.com
Subject: INFO: TEMPEST companies
Message-ID: <9212170133.AA11380@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


Lindgren RF Enclosures
400 Gigh Grove Blvd.
Glendale Heights, IL 60139

Contact: Wayne Martin
708-307-7200
FAX: 708-307-7571

"LT" Series Shielding System is a complete line of modular enclosures,
equipment cabinets and custom enclosures available in virtually all
shielding materials.  The system features exclusive Double Electrically
Isolated construction for maximum attenuation.  All enclosures are fully
tested and guaranteed.  Aplication assistance available.




Secure Systems & Services
Div. of The R/H Factor Corp.
13990 Goldmark Dr., Ste.401
Dallas, TX 75240

Contact: Ray Helsop
214-907-9288
FAX: 214-669-9160

TEMPEST Products, Systems & Services are for Military/Industrial firms
concerned with threat of information security and protection by [sic]
electronic eavesdroppoing; also commercial EMI/RFI, reduced emissions
products.  We provide TEMPEST service and support, data encryption,
F.I.S.A. Facility Information Security Assessment Studies, site planning,
installation design, facility upgrades, etc.




International Paper Co.
Longmeadow Rd.
Tuxedo, NU 10987

Contact: Larry Fahy
914-577-7247

SAF'N SHIELDED (tm)

International Paper provides a unique wallcovering that prevents
electromagnetic interference (EMI), wireless electronic espionage, and
other forms of electromagnetic eavesdropping.  The new wallcovering, a
composite structure that incorporates a nonwoven mat of metallic fibers,
has been TEMPEST-tested by the U.S. government and can achieve attenuation
levels over 100dB.  The material, which eliminates the added costs of
"hardening" or adding protective shielding to individual pieces of
electronic equipment, is being used both in primary applications and to
upgrade facilities to higher levels of protection.  It also provides a way
to plug EMI leaks quickly and effectively.  Unlike woven or sheet metal,
which typically require gutting entire rooms, this flexible, lightweight
material goes up as quickly as wallpaper.  No special tools are needed, and
downtime is minimal.




Transaction Security, Inc.
21 Industrial Ave.
Upper Saddle River, NJ 07458

Contact: O. Mark Hastings
201-573-1150

Steel TEMPEST-type enclosures for any size computer hardware.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Wed, 16 Dec 92 19:13:38 PST
To: treason@gnu.ai.mit.edu
Subject: Re: files
Message-ID: <9212170234.AA14757@maggie.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


> From: treason@gnu.ai.mit.edu
>    Of course half the problems with realistic discussions are aroused
> by idiots flaming without checking their sources....
> 
> treason

Gee, who's the fool claiming that its illegal to RF shield your computer...

.pm




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill O'Hanlon <wmo@rebma.rebma.mn.org>
Date: Wed, 16 Dec 92 22:45:56 PST
To: cypherpunks@toad.com
Subject: A stupid move
Message-ID: <m0n2Dpl-0007g1C@rebma.rebma.mn.org>
MIME-Version: 1.0
Content-Type: text/plain


Edgar Swank helpfully pointed out that I messed up when I sent my
remailer and personal keys out.  I sent the wrong personal key.
Here's both, once again.  
Here's mine:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAiq/Z6sAAAEEAL8au0gDOEj8xQbaV8jS1BM+baetvF6RciEeyfb9A/1Csdpz
87PTEN19tIteDOX8bQIS9exwztaEG7Upa9WlPs9bNsn5TITJAtEOIalqRwlWd1Qh
dsrX7jkytL89MFlVTdBWHhlVuKiGTa4yrFcycoiakXPmf51f0xiQVHeOVJ+HAAUT
tCBCaWxsIE8nSGFubG9uIDx3bW9AcmVibWEubW4ub3JnPokAlQIFECsT6HDlC9IM
15aj/QEBiucD/iS5u+7ze0X0QVI3cVMrFDmkQpQDWb5mm7uPcaeYra3VGm7+Cfxn
LkqwMkMwPytxxkNC9NvFCsrndrFFmuP8eLVBSQpZinfs/2d2A9AJsVsZAd4uDvP3
CKXpF415zgCWBHUt6JrT+pjk00sKUhQYSgUKj1z1uyYfw3q1AMWjrP5s
=k9RJ
-----END PGP PUBLIC KEY BLOCK-----
Here's the remailer@rebma.mn.org, signed with mine.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD
WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b
yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR
tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKYkAlQIFECsUJGEYkFR3
jlSfhwEB1zgD/1LG9DttNEVPFddxkULPw+AkkbmSolrqJUmVx/3y3QS1AtW+vVqF
0yhgWgvg770b7+xMnwzO/I1nh0FK2shd1Jkx4FVCA5ctyqUzVFjk1NE6VaaRc5Bv
BD1nUxtUheR0WXDc50f+ANHgRNkx22MGRvphseMyXq/Ok88opSn7DIrO
=nBQt
-----END PGP PUBLIC KEY BLOCK-----
-- 
Bill O'Hanlon						 wmo@rebma.mn.org



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hkhenson@cup.portal.com
Date: Thu, 17 Dec 92 01:21:34 PST
To: cypherpunks@toad.com
Subject: Re:  tempest devices and use
Message-ID: <9212170034.1.20498@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


I just sent email the first time, but hey, guys, does this not look
almost exactly like some of the restrictive proposals?  Someone is pulling
your chains.  Just because they don't put a :-) on it does not keep
a posting from being satirical.  Keith




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hkhenson@cup.portal.com
Date: Thu, 17 Dec 92 01:21:36 PST
To: cypherpunks@toad.com
Subject: Re: tempest devices and use
Message-ID: <9212170035.1.20498@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


Actually the posting is a takeoff on the crypto restrictions.  Keith




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 17 Dec 92 11:04:13 PST
To: cypherpunks@toad.com
Subject: Re: TEMPEST not restricted
In-Reply-To: <9212171833.AA11371@novavax.nova.edu>
Message-ID: <9212171902.AA05048@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Yanek Martinson makes some very good points about the legality of
TEMPEST:

> "Treason" writes:
> 
> > Here is parts of the article I posted regarding the legality of the use
> > of emf shielding.  
> [...]
> > PERRY, now I put up, now YOU SHUT UP!
> > sheesh.
> > treason@gnu.
> 
> The article you posted is at least 3 years old, if not older.  I have not
> checked on the legal references quote in the article, but I called up
> Wayne Martin of Lindgren RF Enclosures, and asked him about this.  He
> said that he was not restricted to selling TEMPEST equipment to military
> or government only, and suggested that if I am looking for TEMPEST-compliant
> computers, I should call up a computer manufacturer like IBM or Digital,
> and they would be able to sell such systems to me.
> 
> Maybe things have changed in the last three years since the article was 
> written, or maybe it was incorrect to begin with.  

Thanks, Yanek!

And could I suggest to all of us that we be very careful in the
language we use when disagreeing with others? "Treason's" demand that
Perry now "SHUT UP" is intemperate and counterproductive.

Our list is not moderated, that is, there is no censor or moderator
holding people back when they feel the temptation to spew bile all
over the list. With hundred of folks now on this list, great care must
be taken.

Sorry to waste list bandwidth on this point of list etiquette.

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Thu, 17 Dec 92 11:10:49 PST
To: cypherpunks@toad.com
Subject: New number for Secure Systems & Services
Message-ID: <9211177246.AA724619264@jplpost.jpl.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain


          The new number for SS&S is (214) 907-9288
          Also, Lindgren RF Enclosures informed me that they
          now have exclusive license to market International Paper
          Company's SAF'N SHIELDED; and they give free samples ;-))

          JPW




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "DrZaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Thu, 17 Dec 92 15:42:43 PST
To: cypherpunks@toad.com
Subject: Re: Treason's bile spewing
Message-ID: <44511.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


In Message Thu, 17 Dec 92 11:02:42 PST,
  netcom!tcmay@netcomsv.netcom.com (Timothy C. May) writes:

>Our list is not moderated, that is, there is no censor or moderator
>holding people back when they feel the temptation to spew bile all
>over the list. With hundred of folks now on this list, great care must
>be taken.
>
>Sorry to waste list bandwidth on this point of list etiquette.
>
>--Tim

Well said Tim.  Treason's posts, for the past week, have been like the
rantings of a third grader.  I'm just glad some people on this list have the
resources to prove him wrong.

Oh.. and what kind of prices are we talking about to, say, TEMPEST a small
room.. maybe enuf for a workstation and misc. accessories.  |-]

TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: treason@gnu.ai.mit.edu
Date: Thu, 17 Dec 92 09:38:58 PST
Subject: No Subject
Message-ID: <9212171738.AA02009@spiff.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


Here is parts of the article I posted regarding the legality of the use
of emf shielding.  Read it carefully, and I suggest you also read the
posted document in full as well.  This poses many problems to the public
in general, and the private sector in specific.
PERRY, I suggest you read this.              
 
               NACSIM 5100A is  classified, as are all  details of TEMPEST.
          To  obtain  access to  it, contractor  must  prove that  there is
          demand within  the government for the specific  type of equipment
          that intend to  certify.  Since  the standard is classified,  the
          contractors can not sell the equipment to non-secure governmental
          agencies or the public.  This prevents reverse engineering of the
          standard  for its physical  embodiment, the  Certified equipment.
          By  preventing  the   private  sector  from  owning   this  anti-
          eavesdropping equipment,  the NSA has  effectively prevented  the
          them from protecting the information in their computers. 
               A number of  companies produce  devices to measure  the
          emanations from electrical equipment.  Some of these devices
          are  specifically   designed  for   bench  marking   TEMPEST
          Certified equipment.  This does not  solve the problem.  The
          question  arises:  how   much  radiation  at   a  particular
          frequency  is compromising?  The  current answer is to refer
          to NACSIM  5100A.   This document  specifies the  emanations
          levels suitable  for Certification.   The  document is  only
          available  to United  States  contractors having  sufficient
          security  clearance  and  an  ongoing  contract  to  produce
          TEMPEST Certified computers  for the  government.   Further,
          the correct levels are specified by the NSA and there  is no
          assurance that, while these levels are sufficient to prevent
          eavesdropping by unfriendly operatives,  equipment certified
          under NACSIM  5100A will have  levels low enough  to prevent
          eavesdropping by the NSA itself.
               The  accessibility  of  supposedly  correct  emanations
          levels  does  not solve  the  problem of  preventing TEMPEST
          eavesdropping.     Access   to  NACSIM   5100A   limits  the
          manufacturer to selling the equipment  only to United States
          governmental  agencies  with  the  need  to  process  secret
          information.[33]  Without  the right to possess  TEMPEST ELINT
          equipment  manufacturers  who  wish to  sell  to  the public
          sector cannot determine what a  safe level of emanations is.
          Further  those  manufacturers with  access  to  NACSIM 5100A
          should  want  to  verify that  the  levels  set  out in  the
          document are, in  fact, low enough to  prevent interception.
          Without an actual  eavesdropping device with which  to test,
          no   manufacturer  will   be   able  to   produce  genuinely
          uncompromising equipment.

PERRY, now I put up, now YOU SHUT UP!

sheesh.

treason@gnu.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Thu, 17 Dec 92 12:45:34 PST
To: cypherpunks@toad.com
Subject: Re: New number for Secure Systems & Services
Message-ID: <9212172044.AA04823@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



> and they give free samples ;-))

"Great.  Now does anyone know of where to get equipment to test how
 effective it is?  "

I'd guess that virtually any hardware lab that has to test its equipment
to make sure it meets FCC criteria for minimal emissions, would have a
test lab onsite.

Such a test lab normally consists of the following :

	- a very wide frequency range analyzer ( HP makes these )
	- a set of antennas by which to sample the EMF field(s)
	- a platform adjacent to the antenna mount, upon which
		such equipment as is being tested, is rotated,
		to allow the antenna to sample the entire 360-
		-degree field at incremented altitudes and var-
		-iable angles in incidence.

Those test labs I've been acquainted with are usually found at a distance
from production facilities, usually small outbuildings in fields out back,
insulated by distance from the EMF of the surrounding buildings. I can see
how this paper might make it possible to move the lab back indoors ...

To answer your question specifically, I'd check a HP electronic test products
catalog, with an emphasis on signal/frequency/harmonic analyzers.


-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Thu, 17 Dec 92 12:50:22 PST
To: cypherpunks@toad.com
Subject: SS&S response to TEMPEST inf0 request
Message-ID: <9211177246.AA724625237@jplpost.jpl.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain


          About 30 minutes after I got off the phone requesting
          product information and related materials, I recieved a
          voice mail message from Ray Helsop of SS&S.  When I
          returned his call, he informed me that the address that I
          gave looked like a residential address (Hmmm), and that they
          usually don't send information to private homes, apts,
          bird-baths, e.t.c.

          He then informed me that he had called my employer
          (the Junior Proletarian Laboratory), and varified my name in
          the directory, and the department that I worked in; and that
          since I work for a Federal Research Facility (DoD sinkhole)
          everything was `ok'.

          He then proceded to tell me about foreigners calling the
          company requesting TEMPEST information, and other "spooky"
          callers, and that it was now allright to send the
          product information to my home.

          After I told him my interests in the hardware, he ran down
          a list of avilable equipment, and asked about numbers,
          requirements, and said he'd send it right out to me.

          I hate to be presumptuous... but I think an "I'm trying to
          protect my personal computer from prying eyes" would fall on
          very deaf ears at SS&S, and I'll leave it at that. ;-)

          JPW




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: norm@xanadu.com (Norm Hardy)
Date: Thu, 17 Dec 92 13:51:15 PST
To: cypherpunks@toad.com
Subject: TEMPEST not restricted
Message-ID: <9212172053.AA26480@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


While taxpayers paid for TEMPEST and NACSIM 5100A and it would undoubtedly
be useful to taxpayers were it declassified, it is not true
that compliance with NACSIM 5100A is necessary and sufficient to
be secure from eavesdropping. Some of RSA's charm is that it was not
promulgated by NSA!




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 10:34:01 PST
To: treason@gnu.ai.mit.edu
Subject: TEMPEST not restricted
In-Reply-To: <9212171738.AA02009@spiff.gnu.ai.mit.edu>
Message-ID: <9212171833.AA11371@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


"Treason" writes:

> Here is parts of the article I posted regarding the legality of the use
> of emf shielding.  
[...]
> PERRY, now I put up, now YOU SHUT UP!
> sheesh.
> treason@gnu.

The article you posted is at least 3 years old, if not older.  I have not
checked on the legal references quote in the article, but I called up
Wayne Martin of Lindgren RF Enclosures, and asked him about this.  He
said that he was not restricted to selling TEMPEST equipment to military
or government only, and suggested that if I am looking for TEMPEST-compliant
computers, I should call up a computer manufacturer like IBM or Digital,
and they would be able to sell such systems to me.

Maybe things have changed in the last three years since the article was 
written, or maybe it was incorrect to begin with.  


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Thu, 17 Dec 92 14:12:48 PST
To: cypherpunks@toad.com
Subject: Patent Infringement
Message-ID: <9212172211.AA05449@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



> This does not mean though, that it is illegal to reinvent the wheel and
> apply it yourself.

"I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
 apply it yourself.  In the US it is called "Patent Infringement"."

Only if you attempt to sell it ...


-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Date: Thu, 17 Dec 92 11:19:50 PST
To: treason@gnu.ai.mit.edu
Subject: Re:
In-Reply-To: <9212171738.AA02009@spiff.gnu.ai.mit.edu>
Message-ID: <9212171919.AA27449@tsx-11.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


   Date: Thu, 17 Dec 92 12:38:34 -0500
   From: treason@gnu.ai.mit.edu
   Apparently-To: cypherpunks@toad.com

   Here is parts of the article I posted regarding the legality of the use
   of emf shielding.  Read it carefully, and I suggest you also read the
   posted document in full as well.  

We have read it carefully.  What your article claims is that NACSIM
5100A is classified, so if something is built to be TEMPEST certified,
the design is classified, and the actual device can not be sold to the
public, in order to prevent reverse-engineering of the standard.

This, however, does not mean that emf shielding is illegal.  How to do
emf shielding is relatively well understood --- what is classified is
how much shielding is enough.  As your article itself admits, having the
the NACSIM standard isn't very useful anyway, since we can't trust the
levels promulgated by the NSA to be sufficient to prevent them from
listening in.  (What you're saying would be like saying that the NSA has
a classified recommendation that RSA keys be at least XXX bits long ---
just because the recommendation is classified doesn't mean that we can't
use RSA, and if the number of bits were something like 512 bits, if we
found out what it was, we'd probably want to use something bigger
anyway.  :-)

As many other people have pointed out, emf shielding can't be illegal,
since it's required for FCC requirements.  If someone wants to spend
additional money, and put a lot more shielding that what's really
needed, there shouldn't be any problem with that.

Finally, I'm not sure about the complete accuracy of that article you've
posted.  We have one of the first BBN Safekeeper (tm) boxes at MIT,
which is a certificate meter which generates X.509 public key
certificates for use in the Privacy Enhanced Mail (PEM) system.  It *IS*
TEMPEST shielded(*) and BBN is planning on selling it to commercial
companies, TEMPEST shielding and all.  Therefore, I suspect that the
information in that article may be out of date.

   PERRY, now I put up, now YOU SHUT UP!

There's no need to be rude --- especially when you're wrong and can't
even interpret the article which you yourself posted.

						- Ted

(*) There is an amusing story about what happened when they took it to
get it certified as a FCC Class A computing device (which they needed to
do since they were planning on selling it commercially); the FCC tester
kept bringing his testing device closer, and closer, and closer to the
Safekeeper(tm), and when he was finally on top of it, he tapped his
meter and asked: ``Are you sure this is turned on?''  As the story was
told to me, the designer of the box was there for the testing, and this
was one of his prouder moments.  :-)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Thu, 17 Dec 92 12:53:31 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9212171925.AA04923@maggie.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


Close, but no cigar, Mr. "Treason". Anyone reading your "proof" can see
for themselves that there is no law making it illegal to shield your computers,
only some regulations on people that sell equipment to the government can't
tell other people what their specifications are. Big deal.

The line in the article saying 
          Without  the right to possess  TEMPEST ELINT
          equipment  manufacturers  who  wish to  sell  to  the public
          sector cannot determine what a  safe level of emanations is.
is mostly bull, in the sense that people can probably judge what is safe
without knowing the government standards. In any case, you have demonstrated
nothing making it illegal to shield your computers, and we've already seen
a post containing a dozen purveyors of shielding equipment. Repeating,
you don't know what you are talking about. Now go away.

Perry

Original message included for reference:


> From cypherpunks-request@toad.com Thu Dec 17 14:13:11 1992
> Date: Thu, 17 Dec 92 12:38:34 -0500
> From: treason@gnu.ai.mit.edu
> Content-Length: 3194
> 
> Here is parts of the article I posted regarding the legality of the use
> of emf shielding.  Read it carefully, and I suggest you also read the
> posted document in full as well.  This poses many problems to the public
> in general, and the private sector in specific.
> PERRY, I suggest you read this.              
>  
>                NACSIM 5100A is  classified, as are all  details of TEMPEST.
>           To  obtain  access to  it, contractor  must  prove that  there is
>           demand within  the government for the specific  type of equipment
>           that intend to  certify.  Since  the standard is classified,  the
>           contractors can not sell the equipment to non-secure governmental
>           agencies or the public.  This prevents reverse engineering of the
>           standard  for its physical  embodiment, the  Certified equipment.
>           By  preventing  the   private  sector  from  owning   this  anti-
>           eavesdropping equipment,  the NSA has  effectively prevented  the
>           them from protecting the information in their computers. 
>                A number of  companies produce  devices to measure  the
>           emanations from electrical equipment.  Some of these devices
>           are  specifically   designed  for   bench  marking   TEMPEST
>           Certified equipment.  This does not  solve the problem.  The
>           question  arises:  how   much  radiation  at   a  particular
>           frequency  is compromising?  The  current answer is to refer
>           to NACSIM  5100A.   This document  specifies the  emanations
>           levels suitable  for Certification.   The  document is  only
>           available  to United  States  contractors having  sufficient
>           security  clearance  and  an  ongoing  contract  to  produce
>           TEMPEST Certified computers  for the  government.   Further,
>           the correct levels are specified by the NSA and there  is no
>           assurance that, while these levels are sufficient to prevent
>           eavesdropping by unfriendly operatives,  equipment certified
>           under NACSIM  5100A will have  levels low enough  to prevent
>           eavesdropping by the NSA itself.
>                The  accessibility  of  supposedly  correct  emanations
>           levels  does  not solve  the  problem of  preventing TEMPEST
>           eavesdropping.     Access   to  NACSIM   5100A   limits  the
>           manufacturer to selling the equipment  only to United States
>           governmental  agencies  with  the  need  to  process  secret
>           information.[33]  Without  the right to possess  TEMPEST ELINT
>           equipment  manufacturers  who  wish to  sell  to  the public
>           sector cannot determine what a  safe level of emanations is.
>           Further  those  manufacturers with  access  to  NACSIM 5100A
>           should  want  to  verify that  the  levels  set  out in  the
>           document are, in  fact, low enough to  prevent interception.
>           Without an actual  eavesdropping device with which  to test,
>           no   manufacturer  will   be   able  to   produce  genuinely
>           uncompromising equipment.
> 
> PERRY, now I put up, now YOU SHUT UP!
> 
> sheesh.
> 
> treason@gnu.
> 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 11:38:00 PST
To: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Subject: Re: New number for Secure Systems & Services
In-Reply-To: <9211177246.AA724619264@jplpost.jpl.nasa.gov>
Message-ID: <9212171936.AA14894@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


>           The new number for SS&S is (214) 907-9288

I just called them on the old number earlier today, and they answered.
Maybe they have call forwarding.

>           Also, Lindgren RF Enclosures informed me that they
>           now have exclusive license to market International Paper
>           Company's SAF'N SHIELDED;

Makes some sense.  Someone looking for RF shielding is more likely
to buy it from someone named Lindgren RF Enclosures than from a
paper company.

> and they give free samples ;-))

Great.  Now does anyone know of where to get equipment to test how
effective it is?  





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Doug.Brightwell@Corp.Sun.COM (Doug Brightwell)
Date: Thu, 17 Dec 92 15:48:52 PST
To: cypherpunks@toad.com
Subject: TEMPEST Question
Message-ID: <9212172348.AA01767@media.Corp.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain



Am I correct in understanding that what's actually detected and
reconstructed by TEMPEST surveillance is the EMR having to do with
screen drawing, and not the CPU and other internal components involved
in processing data?

If that's the case, would computers without CRT-type displays still be
succeptible to TEMPEST surveillance? Such as headless servers that
might be running a BBS without a video card inside or a monitor. Or
laptops, such as a Mac PowerBook with an active-matrix screen?

Thanks,
Doug



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 17 Dec 92 16:23:45 PST
To: cypherpunks@toad.com
Subject: Faraday Cages
In-Reply-To: <44511.drzaphod@ncselxsi>
Message-ID: <9212180022.AA21357@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



> Oh.. and what kind of prices are we talking about to, say, TEMPEST a small
> room.. maybe enuf for a workstation and misc. accessories.  |-]
> 
> TTFN!
> 
> DrZaphod

The usual, and cheaper, approach is to shield a computer or
workstation. This is the approach discussed in the last several days
here.

Shielding a room is common is certain applications, such as at NSA
(where the entire windowless building is so shielded), in component
testing labs, and so on. Such rooms are called Faraday cages.

It so happens that in 1972 I worked inside such a Faraday cage (in the
labs at UCSB of then-young Paul Hansma, now famous in the nanotech
community for his AFM imaging of cells and other biological
materials). The shield consisted of copper screen mesh
(fine-pitch...perhaps .5 mm gaps) mounted on a wooden frame, with 2
layers and an air gap between them. 

Attenuation depends on frequency, of course, and a wire mesh screen
lets through some frequencies (light, for example!). How many dbs of
attenuation at "frequencies of interest" depends on a lot of factors.
Extremely high frequency signals, becoming more common in computers as
processor speeds exceed 50 MHz, are very hard to shield, due to the
short wavelengths.

I suspect if the boys in the antenna-equipped vans are parked outside
your home, nearly any leakage is too much. But there are cheaper ways
for your secrets to be learned. In other words, there are more
pressing concerns.

I would estimate that shielding an entire room would be expensive,
perhaps costing $5K or more ot do a good job. Building a smaller
room-within-a-room might cost a little less.

Listening to a radio is one very crude way of monitoring your own
RF emissions, if you don't have access to specialized gear.

Using a laptop helps. (I have an old GRiD Compass, with plasma
display, bubble memory, and a black magnesium case...it is definitely
less RF-noisy than my PowerBook, and a lot less noisy than my IIci.)

(Perhaps Phil Karn can comment on strategies)

BTW, we've talked about setting up our own "van Eyck radiation"
systems to see just how easy it is to monitor computers. There is a
legend, possibly urban, that the NSA did indeed try to block
publication of papers on the "van Eyck" effect. This fits part of what
"Treason" was saying, though not all of it. (And there is no law
saying you can't try to shield your computers, or speak in a low
voice, for that matter.)

--Tim

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 17 Dec 92 16:36:15 PST
To: cypherpunks@toad.com
Subject: The Need for Positive Repuations
In-Reply-To: <9212172333.AA12866@toad.com>
Message-ID: <9212180034.AA23003@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Tai (UFLTAI@MEMSTVX1.bitnet) asks about how best to stop people from
generating many, many digital pseuodonyms, thus evading filtering by
"Kill" files. Lots of issues here.

The longterm solution is to use "positive reputations" and not just
"negative reputations" (as in Kill files). This is something Dean
Tribble just talked about at our last physical meeting of the
Cypherpunks ("Bay Area Branch" :-} ).

Think of like a credit rating. People _earn_ trust, they don't just
get assigned a credit rating until they do something bad. 

Positive reputation filtering will still allow digital pseudonyms, but
a reputation will be attached and will be important. Read Vinge's
"True Names" for some insights on this.

--Tim


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Derek Atkins <warlord@MIT.EDU>
Date: Thu, 17 Dec 92 13:38:49 PST
To: dclunie@pax.tpa.com.AU (David Clunie)
Subject: No Subject
In-Reply-To: <9212172122.AA00432@britt>
Message-ID: <9212172137.AA04528@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


> This does not mean though, that it is illegal to reinvent the wheel and
> apply it yourself.

I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
apply it yourself.  In the US it is called "Patent Infringement".
Now, this may not apply to EVERYTHING, but there are cases where
people re-invented something that was classified and their work then
became classified....

(I also believe there are stories where the opposite is true, but I
don't want to belabor the point)






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Derek Atkins <warlord@MIT.EDU>
Date: Thu, 17 Dec 92 13:38:54 PST
To: dclunie@pax.tpa.com.AU (David Clunie)
Subject: No Subject
In-Reply-To: <9212172122.AA00432@britt>
Message-ID: <9212172137.AA04531@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


> This does not mean though, that it is illegal to reinvent the wheel and
> apply it yourself.

I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
apply it yourself.  In the US it is called "Patent Infringement".
Now, this may not apply to EVERYTHING, but there are cases where
people re-invented something that was classified and their work then
became classified....

(I also believe there are stories where the opposite is true, but I
don't want to belabor the point)

-derek




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 13:53:18 PST
To: cypherpunks@toad.com
Subject: 1st dc-net works!
Message-ID: <9212172152.AA20073@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


Finally, I got a dc-net working.  It is now quite primitive, and useful
only as a proof of concept.  It does not yet do any key management, I
just copied the binaries of several unix utilities to be used as one
time pads.  The reservation system does not work yet.  If there is a 
message to be sent, it is sent immediately.  That means only one
of the participants can send a message in one round.  The messages
are not forwarded anywhere, they are just dropped to "outgoing" 
directory.  

It runs on one machine, under three accounts I created just for that 
purpose.  The mail keeps going back and forth constantly between the
three accounts, with null files being deposited to the outgoing
directories.  

Temporary files are being created and deleted.

As soon as I put a file in one of the incoming directories, within one
round it appears in each of the outgoing directories.

So the main function works.

It is written in perl, because of the ease I can manipulate binary data
of any size.

As soon as I add the minimal necessary features (PGP based key exchange,
and reservation blocks) I will be looking for some people to participate
in an experimental dc-net.  People who want to participate in this, should
have fast, reliable, e-mail connections (preferably round-trip time
to any other participant should be less than 10 minutes).  If even one
participant has a slow link, it will hold everyone up.  You also need
the ability to pipe incoming mail with a certain subject header through
an arbitrary program.  You can use any of the various 'slocal' programs,
or you could use elm's filter program, or any other means.  You also need
to have perl working on your system.  You need PGP.  

As someone suggested, an arbitrary group of people might not have much
to talk about amongst themselves, so the next feature will be forwarding
to a mailing address (or list), a newsgroup, or another dc-net.  It is
very simple to do the forwarding, it is a little more complicated,
and interesting, to decide who will do the forwarding.  I would not
want to rely on any single site serving as a gateway, since that
would introduce a single point of compromise.  I would rather have
some dynamic system, similar to the reservation blocks, that would
let the net randomly decide who will forward a particular message.

As soon as this first test network has run for a couple of days, and all
the bugs are fixed, I will release the code, so that anybody can work
on it.  I expect that some people will work on various projects I mentioned
in the "FUTURE ENCHANCEMENTS" section of my initial posting on this
topic.  I hope that people who add features to the system send the mods
back to me, so I can incorporate them in a new version.

When there is a number of networks running, it will be interesting to
experiment with hierarchical nets, or linked networks of networks.  


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Thu, 17 Dec 92 17:40:08 PST
To: uunet!CUNYVM.CUNY.EDU!UFLTAI%MEMSTVX1.bitnet@uunet.UU.NET
Subject: abusing the system?
In-Reply-To: <9212172333.AA12866@toad.com>
Message-ID: <9212180105.AA28598@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


	 Date: Thu, 17 Dec 92 17:33 CDT
	 From: uunet!CUNYVM.CUNY.EDU!UFLTAI%MEMSTVX1.bitnet
	 X-Vms-To: IN%"cypherpunks@toad.com"

					 I realise that this is probably not important in the overall scheme of
	 things... but I am curious about what can be done to reduce such potential
	 abuse.

You will be happy to know that solving that problem will be extremely
important (probably even in the short term).  We need a positive
reputation system (kill files filter against negative reputations) so
that you only see mail messages by people who have a reputation for
valuable postings.

I rambled about this topic at the last cypherpunks meeting.  I will be
posting my notes in an effort to get feedback and organizational help
from the people on the list (it will be a few days, however).

The content will eventually be organized into something that I hope
will spread.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Doug.Brightwell@Corp.Sun.COM (Doug Brightwell)
Date: Thu, 17 Dec 92 17:27:21 PST
To: yanek@novavax.nova.edu
Subject: Re: TEMPEST Question
Message-ID: <9212180126.AA01855@media.Corp.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain


	>> Cpu signal is the easiest to detect, but not the only
	>> one.  Other possible sources of emissions are all
	>> kinds of communications cables.  Unshielded RS-232 to
	>> the modem, possibly even the connections to the disk
	>> drives.

Synching up to monitor signals, I can understand.

But as a non-technical person, what I'm struggling to understand is how
a surveillance team could monitor the emmisions from such cables and
have any clue as to what they are. Let's say they zeroed in on my
poorly shielded modem cable and were able to tune into a stream of 0's
and 1's. How could they then resolve that digital data into anything
meaningful? It could be one of any number of documents created by one
of any number of programs on one of any number of platforms. How do the
spies know they're dealing with a Frame page layout document created on
a Sun workstation versus a spreadsheet created on a Mac?

Even if it's just a plain text file how could the surveillance team
read it? Does each member of the ASCII character set have specific and
identifiable radiation signatures? For example, does the letter "k" as
it passes through my modem cable have a characteristic EMR that is the
same for all machines?

Sorry if this query is too basic, but I would appreciate any enlightenment...

Doug



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: UFLTAI%MEMSTVX1.bitnet@CUNYVM.CUNY.EDU
Date: Thu, 17 Dec 92 15:33:28 PST
To: cypherpunks@toad.com
Subject: abusing the system?
Message-ID: <9212172333.AA12866@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Hiya,
        One of the newsgroups I was reading have this persistant "tester" who
uses the anon service in Finland.  Anyway, there were several different
postings, all with different ids, but same kinds of "this is a test, nyah nyah"
contents.
        As I was one of those "stop it" people, and seeing more of the same
bullshit by that guy, I got slightly pissed off, and started thinking.  Already
that person is using about 3 different anonymous ids.  If he is introduced to
the remailers here, conceivably he could generate more anonymous ids for
himself (ie, kill files won't work then, unless you want to kill a whole site)
by routing his mail thru the remailers.  Each remailer would give him another
userid at that anon service.  And if he uses it to loop back to the
remailers...  And then loop to that Australian anon service... and so on.  He
could "legitimately" have a hundred or so different anon_ids, from one original
userid.
        What if someone who realises this was to use that capability to post
some really "colorful" material to news?  Suddenly you have a hundred or so
weirdos posting "I want nude pictures of a gerbil, please" to alt.binaries.
pictures.erotica... you get the idea.  Is there anyway to stop this from
happening?  And this is on top of the real weirdos (ie, those who know how to
post anonymously, like most of the readers of this list... :))
        So far, the net has functioned as it's own sieve with regards to the
"weirdos" but if the remailers is generally available (as it should be!), the
potential for abuse is much much greater.  Any way to slow it down?  "Hey,
look, a flame war, let's join in..."
        Of course, if someone was to forge a mail to the anon service... don't
even need to know about the remailers...  but with forged mail, the anon
service can at least "check" to see the validity of your address.
        I realise that this is probably not important in the overall scheme of
things... but I am curious about what can be done to reduce such potential
abuse.
        Ciao.

-Tai
ps:  Any tips on tracing anonymous mail and newspostings?  I mean beyond the
"from" and "path" things... ie, trace to the userid...  Someone tried to forge
a posting in my name... (yes, that's what got me thinking :))




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Thu, 17 Dec 92 17:38:36 PST
To: cypherpunks@toad.com
Subject: Re: Treason's bile spewing
Message-ID: <9212180136.AA06221@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



"Treason's posts, for the past week, have been like the rantings of a
 third grader."

This is in itself rather derogatory and does nothing to quell the flames.

"I'm glad some people on this list have the resources to prove him wrong."

I suspect the gentleman in question was not displeased to learn something
new, and, by contributing material that _was_ a few years out of sync, he
was not trying to lower the quality of the discussion ... or dominate it
... he was trying to contribute.

Easy does it, folks.


-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 14:55:51 PST
To: tcmay@netcom.com (Timothy C. May)
Subject: enabling technologies
In-Reply-To: <9212172233.AA06614@netcom.netcom.com>
Message-ID: <9212172254.AA21668@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> I'm amazed at the progress everybody's making on so many fronts.
> 
> --Tim

What we are witnessing (and participating in) here is the synergy of 
enabling technologies.  The availability of quality free software
such as perl, and C compilers makes it easy to quickly build useful
tools.  These can then be combined in various ways, without re-inventing
them.  For example, I do not need to reinvent the strong-pseudorandom
function, I can just "borrow" it from the PGP code.  I do not need to
write a public key system just to distribute seeds for the dc-net 
one-time pads system, I can use PGP.  I don't need to write a program
to take chunks of data and xor them together, perl has this capability.

I just design a system, and put it together from existing blocks.  This
is the reality of what the OOP "building-blocks" people are talking about.

And the important method is not object-oriented anything, but free
software, with source code, and cooperation of people widely separated
in time and space, some even anonymous, all linked through the nets.

My dc-net system will make life easier for people that are doing digital
cash, by providing a ready means of sending untraceable messages.

Many useful systems can be built on top of a working digital cash system.

All this is catalysed by the existence of this mailing list.  For example
I got the idea of reservation blocks from ILF's post of Chaum's article.

That was made possible by the anonymous remailers.

The anonymous remailers can be made more anonymous by linking then into
a dc-net.

There's a positive feedback loop developing here.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 15:00:07 PST
To: rchilder@us.oracle.com (Richard Childers)
Subject: Re: Patent Infringement
In-Reply-To: <9212172211.AA05449@rchilder.us.oracle.com>
Message-ID: <9212172259.AA21750@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> "I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
>  apply it yourself.  In the US it is called "Patent Infringement"."
> 
> Only if you attempt to sell it ...

No.  The patent law prohibits anyone from "making, using, or selling" 
anything covered under the patent.  Selling it makes it more likely
that the patent holder will come after you, as they have a greater
chance of getting some money from you.

I am not a lawyer, I am sure someone here can explain all this in
greater detail, or correct me if I'm wrong.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Thu, 17 Dec 92 15:59:41 PST
To: UFLTAI%MEMSTVX1.bitnet@CUNYVM.CUNY.EDU
Subject: re: abusing the system?
In-Reply-To: <9212172333.AA12866@toad.com>
Message-ID: <9212172358.AA07292@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


>> ps:  Any tips on tracing anonymous mail and newspostings?  I mean beyond the
>> "from" and "path" things... ie, trace to the userid...  Someone tried to forge
>> a posting in my name... (yes, that's what got me thinking :))
	Remember to look at the "Message-Id" -- on typical unix
mailers, that has the IP address encoded into it to help make it more
"unique". 
	A social point to keep in mind, though: one reason we really
*need* signed messages is because there is no real identity attached
to email. It is easy to "believe in" some identity you see on the net,
and for the most part enough of them are real that it is ok... but
I expect this to become even more of a problem than it is now without
signatures.
	A "historical" example -- at MIT, as part of Project Athena,
we have a real-time messaging system called Zephyr (for more details,
look in Usenix proceedings from some time in 87 or 88, or just look at
athena-dist.mit.edu:pub/usenix/zephyr.PS.) It optionally uses kerberos
authentication, and the recipient application will display whether a
message is authenticated or unauthenticated. People tended to ignore
this, until one of the other developers wrote a program that looked at
the database of current users, picked a pair at random, picked a
message at random, and sent it to one, from the other. (It backfired
amusingly once -- it sent a message from him, to me, saying "I'm
stopping at the coffeehouse, want me to get you anything?" to which I
responded sure... and then harassed him about it for years, until he
finally *did* bring me the M&M's I wanted. :-)
	The point was that this program didn't fake the authentication
(it did use privileged access to look at the user database, which is
not available remotely, but the messages themselves were
unauthenticated) but rather noone paid attention to it. The
"unauthenticated" flag was made more visible in a later release, I
believe... but I don't think anyone ever went as far as refusing
unauthenticated personal messages altogether. I could see that
happenning with email...
				_Mark_ <eichin@athena.mit.edu>
				MIT Student Information Processing Board
				Cygnus Support <eichin@cygnus.com>





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Mark W. Eichin" <eichin@cygnus.com>
Date: Thu, 17 Dec 92 16:09:11 PST
To: ncselxsi!drzaphod@ncselxsi.netcom.com
Subject: TEMPEST pricing
In-Reply-To: <44511.drzaphod@ncselxsi>
Message-ID: <9212180008.AA07304@tweedledumber.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


>> Oh.. and what kind of prices are we talking about to, say, TEMPEST a small
>> room.. maybe enuf for a workstation and misc. accessories.  |-]
	I don't know about an entire room, but I seem to recall that
Sun has TEMPESTed workstations on the GPO pricelist, as do other
companies... and that a few years ago TEMPESTed PC's (286 boxes)
*started* around $10K. Most of this was because of the limited market
-- I doubt you'll find a mass-market PC that hasn't skimped as much as
possible on the RF shielding if it was cost effective (BYTE, Oct. or
Nov., or maybe the laptop issue, mentions Apple switching from
sprayed-on metallic paint on the inside of their cases to sheet-metal
liners because it ended up being significantly less expensive.) Given
the lack of a large-volume market to produce economies of scale, you'd
expect the prices for TEMPESTed hardware to stay high.
	Over at MIT, in building 20, there's a room that is entirely
RF shielded (built in place, years ago...) I don't know the story
behind it, I don't know if the shielding is even maintained any more,
it is decades old. It's now random lab-space...
							_Mark_




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 16:28:15 PST
To: Doug.Brightwell@Corp.Sun.COM (Doug Brightwell)
Subject: Re: TEMPEST Question
In-Reply-To: <9212172348.AA01767@media.Corp.Sun.COM>
Message-ID: <9212180027.AA24433@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> Am I correct in understanding that what's actually detected and
> reconstructed by TEMPEST surveillance is the EMR having to do with
> screen drawing, and not the CPU and other internal components involved
> in processing data?

Cpu signal is the easiest to detect, but not the only one.  Other possible
sources of emissions are all kinds of communications cables.  Unshielded
RS-232 to the modem, possibly even the connections to the disk drives.

I don't think the cpu itself emits much or if it does that it is easy
to interpret it in any easy way, but I don't know for sure.

The monitors are just easiest to detect, since for every pixel, the
electron beam is turned on and off.  These pulses are easy to detect, 
and if your monitor is synchronized with the target, a simple device
could reconstruct the image, without any need for powerful computers
to process the data.

> If that's the case, would computers without CRT-type displays still be
> succeptible to TEMPEST surveillance? 

It would be safe to say that they would be _less_susceptible_.

> might be running a BBS without a video card inside or a monitor. Or
> laptops, such as a Mac PowerBook with an active-matrix screen?

Anyone that knows NSA's capabilities in these areas certainly isn't
talking.  It _may_ be possible to derive at some limits just by
knowing electronics and the laws of physics.  I don't know of any 
independent research team having done such a study.  If it has been
done, or is being done, I would like to know.






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 17:23:42 PST
To: yanek@novavax.nova.edu  (Yanek Martinson)
Subject: my mistake (re: TEMPEST)
In-Reply-To: <9212180027.AA24433@novavax.nova.edu>
Message-ID: <9212180122.AA26838@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> > reconstructed by TEMPEST surveillance is the EMR having to do with
> > screen drawing, and not the CPU and other internal components involved
> 
> Cpu signal is the easiest to detect, but not the only one.  Other possible

Sorry, I meant "display signal". 





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Thu, 17 Dec 92 20:48:27 PST
To: cypherpunks@toad.com
Subject: So you want a wide-spectrum signal analyzer ?
Message-ID: <9212180447.AA06689@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain



Here's what HP's catalog says :

	Spectrum Analyzers

	Spectrum analyzers take advantage of the frequency-conversion
	properties of the swept-tuned heterodyne receiver to make sig-
	-nificant contributions to frequency-domain signal analysis.
	The following are some of the measurements that can be made with
	spectrum analyzers :

	(1)	Absolute and relative frequency.
	(2)	Absolute and relative amplitude.
	(3)	Noise.
	(4)	Distortion products.
	(5)	AM, FM & pulsed RF modulation.
	(6)	Stimulus response.		( biofeedback ? ed. )
	(7)	Electromagnetic compatibility (EMC).

	These measurements are possible because spectrum analyzers have
	the following characteristics :

	(1)	Broad frequency coverage from 5 Hz to 325 GHz.
	(2)	Wide amplitude range from -138 dBm to +30 dBm.
	(3)	Excellent sensitivity for low-signal detection.
	(4)	Excellent frequency stability.
	(5)	High resolution of frequency and amplitude.

	These capabilities allow spectrum analyzers to provide frequency-
	domain signal analysis for numerous applications, including the
	manufacture and maintenance of microwave communication links, radar,
	telecom equipment, CATV systems, and broadcast equipment ; EMI
	diagnostic testing ; and signal surveillance.

( I can't believe they actually said that. Gee, I wonder if They're going
  to classify test & measurement equipment next. )-:

Prices for these puppies run from @ $ 20,000 to @ $ 50,000. They are very
modularized, and, for the paranoids amongst you, these things are portable.
They are probably devilishly heavy, like most test equipment is, and look
a lot like an oscilloscope, when the cover is off.

	For information about any Hewlett Packard product or service, or
	for additional copies of this catalog, call the Customer Infor-
	-mation Center (CIC) at 800-752-0900 between 6:00 am and 5:00 pm
	PST.

What you want is their 'Test & Measurement Catalog'.

One small tip - if you're calling them up and want to get a catalog sent
to you, you want to make an effort to look like a valid customer. These
catalogs are large and expensive and they may be less inclined to pay for
what is probably a few dollars' shipping if you come across as a college
student ( with apologies to college students :-). Give an address if you
can, give yourself a title - R&D engineer is good - a department - R&D -
and, if they ask for a box or mail dept code, you can make one up or say
that you don't have one. ( Using different box numbers going to a same
address is a great way to see who's sharing their mailing list with whom
else, BTW ).

I'm not encouraging you to spoof these folks, merely noting that it is a
regrettable necessity. If you don't present yourself as a prospect, they
may blow you off, and if you give any hint that you don't represent some
sort of company, you are sure to be blown off, presumed to be a waste of
their time. ( Of course, this posting may lead to three or four analyzers,
$ 100-200 thousand worth of sales, but try to persuade a salescritter of
this. :-)


-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: strat@intercon.com (Bob Stratton)
Date: Thu, 17 Dec 92 18:03:16 PST
To: Doug.Brightwell@corp.sun.com
Subject: TEMPEST Question
In-Reply-To: <9212180126.AA01855@media.Corp.Sun.COM>
Message-ID: <9212180202.AA21476@intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


>>>>> Doug.Brightwell@corp.sun.com (Doug Brightwell) writes:

	Doug> But as a non-technical person, what I'm struggling to
	Doug> understand is how a surveillance team could monitor the
	Doug> emmisions from such cables and have any clue as to what
	Doug> they are. Let's say they zeroed in on my poorly shielded
	Doug> modem cable and were able to tune into a stream of 0's
	Doug> and 1's. How could they then resolve that digital data
	Doug> into anything meaningful? ...

My understanding, being only a moderate RF weenie, is that UARTs, the
devices which, more often than not, are driving your serial ports,
generate an emission very much like good old frequency shift keying.
It makes sense - having listened to computers on radios before. Think
in terms of sound first, as it's easier. A given sound represents a
"1", and another tone is "0". You waver back and forth between the
tones to describe the data you're transmitting. 

The idea is that some of the normal emission characteristics from
components in computers (like UARTs) correspond to this sort of
modulation. 

With regard to machine types, if it's a serial line, it's fairly easy
to map the communications into a set of probably protocol suites. If
you know *anything* about the use of the machine, it becomes a lot
easier. For instance, given an intercept of TCP/IP traffic over a SLIP
line, I could probably reconstruct a TELNET session log, but it's
nowhere as easy as just reading a terminal session on a link to some
BBS.

	Doug> Even if it's just a plain text file how could the
	Doug> surveillance team read it? Does each member of the ASCII
	Doug> character set have specific and identifiable radiation
	Doug> signatures? For example, does the letter "k" as it
	Doug> passes through my modem cable have a characteristic EMR
	Doug> that is the same for all machines?

You might also think in terms of things other than screens and modem
cables. For instance, many keyboards emit RF as they are used. It's
not irrational to suspect that these emissions might be tied in some
way to the use of the keyboard - I have an old FCC Class A Wyse
terminal that sounds different depending on which keys I hit. Since we
know that every piece of equipment has a uniquely identifiable (even
compared to other units of the same type) emission signature, it's not
too outlandish to expect that different key encodings in a keyboard
might generate different emission patterns.

	Doug> Sorry if this query is too basic, but I would appreciate
	Doug> any enlightenment...

It's weird stuff, and some people would rather not have the world
learning how to do this. In fact, Van Eck's original article is known
to have some deliberate misinformation in it, as the author didn't
want to make it "too easy" to learn how to do this kind of ELINT.


--Strat





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 17 Dec 92 18:14:38 PST
To: Doug.Brightwell@Corp.Sun.COM (Doug Brightwell)
Subject: They have to find you first!
In-Reply-To: <9212180154.AA01889@media.Corp.Sun.COM>
Message-ID: <9212180213.AA29897@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> I would guess that all efforts towards creating secure, encrypted email
> would only cause surveillance groups to focus their efforts more upon
> what's showing up on your screen in plaintext before encryption and

To do that, they need to know who you are and where you are located. They
can't bug everyone.  If a pseudonymous system is used, then it would
be your top priority to make it impossible to connect your pseudonym with
your legal identity.  If you have not already, read Vinge's _True_Names_.

If "they" know who you are and where you are located, many techniques are
available, TEMPEST eavesdropping being only one of them.  Others are
confiscating your equipment, arresting you, threatening you and using you
to track down other people.

So, instead of concentrating on how to shield yourself from surveilannce
once you have been found, concentrate instead on not being found.  You can
maintain a usual identity that you use for normal conversation, but for
anything dangerous use an alternate identity, secure remailers, etc.

You might want SOME shielding, in case "they" take up the practice of
routinely driving up and down the streets looking to randomly find
something (someone) interesting.  

It should be much easier to protect against a casual search.

It may be nearly impossible, and/or useless to protect oneself from a
determined physical attack by a resourceful enemy.

It is much more profitable to prevent the attack.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819

(not in hiding yet :-)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: MAILER-DAEMON@acf3.NYU.EDU (Mail Delivery Subsystem)
Date: Fri, 18 Dec 92 11:53:19 PST
To: habs@acf3.NYU.EDU
Subject: Returned mail: User unknown
Message-ID: <9212180223.AA06621@acf3.NYU.EDU>
MIME-Version: 1.0
Content-Type: text/plain


   ----- Transcript of session follows -----
>>> RCPT To:<cyperpunks@toad.com>
<<< 550 <cyperpunks@toad.com>... User unknown
550 cyperpunks@toad.com... User unknown

   ----- Unsent message follows -----
Received: by acf3.NYU.EDU (5.61/1.34)
	id AA06619; Thu, 17 Dec 92 21:23:18 -0500
From: habs (Harry A. B. Shapiro)
Message-Id: <9212180223.AA06619@acf3.NYU.EDU>
Subject: repeater abuse
To: cyperpunks@toad.com
Date: Thu, 17 Dec 1992 21:23:17 -0500 (EST)
X-Mailer: ELM [version 2.4 PL0]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 544       

In reponse to Dean T. message.

I agree.

Re: low tech - The extropians uses several Perry(TM) filters
to prevent unwanted bounces AND unwanted posters OUT.

For a more high tech solution I can imagine some sort of public or
private key needed to make a post 

- An example being some a public key that was in some manner 
signed by a trusted member of a list - I am weak on the techincal
end/side but basically unless the message is "trusted" it doens't
get through.

-- 
habs@acf3.NYU.EDU
habs@gnu.ai.mit.edu
habs@well.sf.ca.us
habs@panix.com






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Thu, 17 Dec 92 22:53:06 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Positive reps.
Message-ID: <921218064714_74076.1041_DHJ46-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

I was thinking about the idea of positive reputations and thought I'd
mention a few thoughts while waiting to see Dean's notes.

As I understand it, a positive reputation is basically some kind of
recomendation or endorsement of a person by someone else.  It might
be fairly specific, like "so-and-so paid a debt of $50 to me within
the agreed-upon two-week period."  Or it could be more general, like
"so-and-so is, in my opinion, an honest person."

I was thinking of positive reputations that might be relevant to the
problem mentioned of anonymous posting to mailing lists and newsgroups.
As Dean mentions, we can envision a system which uses the opposite of
kill files. Instead, messages would only be displayed from people who
met certain criteria in terms of their reputation credentials.

What would I want to see in the way of such credentials that would help
me decide whether I wanted to read the message?  (The issue of judging
the validity of credentials is discussed below.)  Maybe recommendations
in favor of the poster's intelligence, knowledge, judgment, temperance
(i.e. reluctance to flame), etc. would be useful.  Imagine a system in
which a person was rated from 1 to 10 in each of these categories.  A person's
positive reputation would consist of (digitally) signed statements from
various "endorsers" (or "introducers"), each giving their numeric judgements
about the person in question.

With this system, I could set my ideal mail/news reader to only display
postings from people whose scores met some standards.  Maybe I would
average them; maybe I would weight the different categories according
to my own tastes.  But this would let me filter out time-wasters like
the random poster who was causing problems.

Now, this still leaves open the problem of judging the validity of
various credentials.  This problem is very similar to the problem of
accepting key signatures in PGP.  If I receive a PGP key loaded with
signatures, that doesn't mean much unless I know at least one of the
people involved (either directly, or through the net).  Only then can
I judge how valid the signatures are.

In the same way, if a new person posts on a newsgroup, and includes his
credential loaded with 10/10/10/10's, that doesn't mean anything unless
I know some of these people who are vouching for him.  In the most
extreme case, he could have created a bunch of false identities and had
them provide all the endorsements.  So an endorser unknown to me is
not useful.

It's interesting that the PGP key "web of trust" may have application
to this more general problem.  I wonder if the PEM folks will push for
a centralized "email posting quality" hierarchy in which agencies rate
each person's quality of postings and assign them an official score. :-)
This would be the analog of their solution to the key-signature problem.

That's about as far as I've gotten.  A few more general comments:
Such a system requires an infrastructure of public-key encryption and
digital signatures.  Only in that way will signed credentials be secure
enough to be meaningful.  Since so few people use these tools today,
a positive-credential system would filter out almost everyone, throwing
out the baby with the bath water.

But, remailers are springing up everywhere.  It is an idea whose time
has come, it seems.  So the problem exists today, but the solution can't
be practically applied for at least another year or two, even assuming
rapid acceptance of PGP, RIPEM, PEM, or some other cryptographic standard.
That means that there may be some political pressure against remailers
during this interval.  Perhaps we can turn this to our advantage by describing
the advantages of a credential system, and using that to further encourage
widespread use of cryptographic programs.

Hal Finney
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzFI+KgTA69YIUw3AQEdCQP8DbPD9jrlR1MhlLOOQrSUc8Svcue2DZsj
+DIXiC50bpv+C5pZYtoCa5SuOXX8W6XmZRSkZW3gilvEKDQ2Zt7hH0ol+tFnn8cs
q05T1bYJIZqdMdqia6PZkVyvs+DQLuQSog5rZxAja1XfC/Rq59RnbPp2IViLqDiD
OfiasXA4Egs=
=GVH7
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc Horowitz <marc@Athena.MIT.EDU>
Date: Fri, 18 Dec 92 01:08:33 PST
To: cypherpunks@toad.com
Subject: holiday travel:  sign some keys!
Message-ID: <9212180907.AA07411@portnoy.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


With the holidays coming up, and many of us traveling to see friends
and relatives, we all have a great chance to sign keys of people who
aren't in our normal circle of contact.  In our web of trust, we need
as many long strands as we can get.

I recommend that all of you write down your MD5 hashes, and, if you
are willing, post your general itinerary if you are traveling so
people can get in touch with you, and your key signing policy.  It
only takes a five minute meeting (unless there's good chinese food
conveniently nearby :-) to exchange hashes, then you can email your
keyring once you get back home.  I'll start.

I'll be visiting friends in the Alexandria, VA area saturday and
sunday (12/19-12/20), but I won't be reachable via phone easily so if
you'll be in that area during that time, email me before noon saturday
with contact information.  From sunday 12/20 to wednesday 12/23 (I may
stay later), I'll be in northern New Jersey (Wayne, to be exact) at my
parents' house, phone 201-694-3152.

I only sign keys I can verify out-of-band, either in person or by
phone with someone I know.  So far, all the keys I've signed are
people I've known for awhile and see often, so it was easy.  I guess
I'll make up a new rule: show me a driver's license and another piece
of ID (sort of like what you need to cash a check), and I'll trust
that you're you.  The harder to fake the better; I suppose passports
rank high on that list.

Maybe I'm crazy for posting all this info saying when I'm going to be
out of town, but I think it's worth it in the interest of getting some
more connections established (and I've been accused of being crazy
many times before, anyway).

		Marc




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dclunie@pax.tpa.com.AU (David Clunie)
Date: Thu, 17 Dec 92 13:22:55 PST
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <9212172122.AA00432@britt>
MIME-Version: 1.0
Content-Type: text/plain


> Here is parts of the article I posted regarding the legality of the use
> of emf shielding.  Read it carefully, and I suggest you also read the
> posted document in full as well.  This poses many problems to the public
> in general, and the private sector in specific.
> PERRY, I suggest you read this.              
>  
>                NACSIM 5100A is  classified, as are all  details of TEMPEST.


The information may be classified, as perhaps it should be. If I were an
organization of any kind trying to protect my data I wouldn't run around
publicizing the details of the technology required to protect it either.

This does not mean though, that it is illegal to reinvent the wheel and
apply it yourself.

Besides, who is to say what is an "acceptable" level of EM radiation - the
government has clearly chosen what it considers acceptable levels to
facilitate equipment supply by contractors.

If you want more or less protection then you and any other member of the
public are free to define, manufacture or purchase whatever you want.

And if you can't get it from a local source I am sure there are plenty of
governments and manufacturers elsewhere in the world you can deal with,
though of course exporting the technology may be another matter, but there
is nothing new about that.

There are plenty of other government conspiracies to focus on ! This one
seems a bit lame.

david





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pozar@kumr.lns.com (Tim Pozar)
Date: Fri, 18 Dec 92 08:28:39 PST
To: rchilder@us.oracle.com (Richard Childers)
Subject: Re: So you want a wide-spectrum signal analyzer ?
In-Reply-To: <9212180447.AA06689@rchilder.us.oracle.com>
Message-ID: <m0n2kY8-0002f8C@kumr.lns.com>
MIME-Version: 1.0
Content-Type: text/plain


Richard Childers wrote:
> 	These capabilities allow spectrum analyzers to provide frequency-
> 	domain signal analysis for numerous applications, including the
> 	manufacture and maintenance of microwave communication links, radar,
> 	telecom equipment, CATV systems, and broadcast equipment ; EMI
> 	diagnostic testing ; and signal surveillance.
> 
> ( I can't believe they actually said that. Gee, I wonder if They're going
>   to classify test & measurement equipment next. )-:
   We use them all the time to track down pirate stations and wierd
emissions (spurs, harmonics...).  BTW... If you have an O-Scope that has
X-Y inputs, it isn't that difficult to design and build a low-end, front-end 
for the scope that will provide the same functions as a spectrum analyzer.

> I'm not encouraging you to spoof these folks, merely noting that it is a
> regrettable necessity. If you don't present yourself as a prospect, they
> may blow you off, and if you give any hint that you don't represent some
> sort of company, you are sure to be blown off, presumed to be a waste of
> their time. ( Of course, this posting may lead to three or four analyzers,
> $ 100-200 thousand worth of sales, but try to persuade a salescritter of
> this. :-)

   I think they partially do this 'cause the catalogs are so bloody
expensive to produce.  They are an education if you get one.

         Tim

-- 
    Internet: pozar@kumr.lns.com     FidoNet: Tim Pozar @ 1:125/555
Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA
                        Voice: +1 415 788 2022




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: deboni@diego.llnl.gov (Tom DeBoni)
Date: Fri, 18 Dec 92 09:52:02 PST
To: CYPHERPUNKS@toad.com
Subject: positive reps and paranoia
Message-ID: <9212181748.AA03280@diego.llnl.gov>
MIME-Version: 1.0
Content-Type: text/plain


I'm just a lurker on this list, trying to pick up on what's happening in this
subset of computing and communications, but my chain's been yanked, and the
subject merits a reply. 

On the matter of the discussion that's been going on vis-a-vis reputations
versus kill files, I'm afraid we're regressing to the bad old days when
everyone was considered bad and worthy of suspicion until they demonstrated
that they were good and trustworthy. I'd personally rather believe people
are basically good than otherwise. Even if I must occasionally suffer getting
burned, it's easier on the nerves, attitude, and karma to assume the best
in those I interact with. I think it's significant that there are really so
few of us on the net who are actually insufferable and refuse to be shouted
down to reasonable behavior by the civil rest of us. Those few who are will
not be prevented from troubling us by the measures being advocated - positive
reps, scores on 1-to-10 scales, etc. - any more than weapon makers are
deterred by manufacturers of armor. someone who really wanted to could still
flood our group with vitriol, using multiple artificial identities vouched for
by other artificial identities. If such neurotic vengeful behavior were really
likely on the net, we'd have seen it already. What, other than good sense and
a low threshold of boredom, prevents any of us from flooding any and all news
groups with garbage? And if it ever becomes a problem, we'll just have to
appoint a moderator, perhaps on a rotating basis, from among those of us who
are personally acquainted with each other.

My point here isn't that we shouldn't prepare for the worst, but that we
shouldn't get crazy about it. The theoretical aspects of the discussion are
interesting to me, but I just thought it was getting a little close to the edge
not to comment.

Tom DeBoni
(Once I figure this stuff all out, I'll get a "protected" identity, too.)
deboni@llnl.gov






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Fri, 18 Dec 92 02:31:06 PST
To: cypherpunks@toad.com
Subject: New remailer
Message-ID: <1992Dec18.095552.1987@extropia.wimsey.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

I've set up a new remailer.  I am currently working on extensions.  Here
are the details:

Address: remail@extropia.wimsey.com
Contact: miron@extropia.wimsey.com
Encryption: PGP 2.1
Syntax:
    Compatible with Hal-standard remailers, except for a couple of things:

    - Encryption MUST be used.
    - Syntax can be simplified.  The pasting operator is assumed.
    The "Encrypted:" header is optional.  Accordingly, you can
    just encrypt plaintext of the following form (without the
    cut-here lines):

    --- cut here ---
    To: <recipient>

    <body>
    --- cut here ---

    In any case, one should be able to use the scripts posted
    on cypherpunks without change.

Availability: continuous, approx 2 hr turnaround or better.

(The keys follow this signed message.)

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzGfiZNxvvA36ONDAQHs0AP9EO5eiynLcTZumU7l4I+uLTvwROHR+DVv
LfFDV5/dKtSaISQpYvj2RSKYK3NHi2JiCM5vnkNYUWFW1uHcX/BpdOte8IJr2zML
/lpEEOYgbi56OGqg2bYhBCbJuh2wY71Ibs5Z5C/1HHsJ8hC334nbOV8pKC+gr+Mi
Am+tEzExRyM=
=Af9o
-----END PGP SIGNATURE-----

Remailer Key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAisrAP0AAAEEAJr3OwIfOIOoh9JndwwqFg+VyWFTAyM8S0B7wyGKI+A9sMAB
mbSOIU52EszvLdZk8NH8mrOD9m3EZlt9gXOjln881RMilAunnzdXaJ6ffBKqPL+l
yiefCbCo6wScVNfMSV6Di/2HMoFzVqukwRjTx8lqKt6hgy0uedtwcCemtaMvAAUR
tCVSZW1haWxlciA8cmVtYWlsQGV4dHJvcGlhLndpbXNleS5jb20+iQCVAgUQKysE
i5NxvvA36ONDAQF2AAP+IQlQxQ9MxuO6WDzIPsuzTxOS5LVrdh3MLWeAkbk+QN3l
hrRvEneULh82xOEvZg9whZ+/W8WYtFA4a8g/HbAhuHh4gqQHGakr0SUpKYGpnUWl
EBzZjMb+YKMR4UXpusF6ysWUDZ+f0tDbUDq0ukCoRZRq8wyIf9mndSfaqcsyfyGJ
AEUCBRArKwPUS60iYsR4D/cBATXBAXsFqc8sCpP0gQ8KHF3myZrE+s7oP2nu/FP3
LvZE1+ttF3I9c6jncfWPT6cHpvWEoWk=
=ZZ5t
-----END PGP PUBLIC KEY BLOCK-----

My key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqvJ10AAAED/jXfntqmsRjJRYoxYTxLO7obzMfzgUNtSDEawb3Suj4UO1xq
uARc25PJNAHQhIa83Yxf9z/R/3AjwmYrZqxvB2RkLPTjTmzQd04fypsZToiR/TlM
5F43JCuCM779mAir9Idy1CQzXQ2bn89eUZaVhOUJzNgndl+wLpNxvvA36ONDAAUR
tCxJbW1vcnRhbCBGcmVlZG9tIDxtaXJvbkBleHRyb3BpYS53aW1zZXkuY29tPokA
lQIFECsXPLSTcb7wN+jjQwEBv20D/jIKu8z9DP+wTLLWYZZax9wnJJzRkD9//kFA
C0is6LMNMSSX0yGwOPmqEI710BSovuTAlNBmqBrMrl0Bp5bsxpCN8Fw3Mc0ex5fe
1efockVjXNLMP0G4plr0AFMA4KXNE+MfwLFMd+Gcdxufro0yKoBygsHwQ+om+rut
RPIy89/PiQBFAgUQKwxwHUutImLEeA/3AQGQnQF8D0Zdrrz+kMAguOANBhbnxm5t
zak4TWg37hp/iU2CEfIbW/IUVIPEjNhvM6cjZ1jQ
=/SVk
-----END PGP PUBLIC KEY BLOCK-----
-- 
	Miron Cuperman <miron@extropia.wimsey.com>  | NeXTmail/mime ok
		       <miron@cs.sfu.ca>	    | Public key avail
	AMIX: MCuperman				    |
cybercomputingimmortallaissezfaire		    |




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 18 Dec 92 11:24:15 PST
To: cypherpunks@toad.com
Subject: Re: Patent Infringement
Message-ID: <9212181618.AA29313@maggie.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


> From: yanek@novavax.nova.edu (Yanek Martinson)
> 
> > "I'm sorry to say that yes, it *IS* illegal to reinvent the wheel and
> >  apply it yourself.  In the US it is called "Patent Infringement"."
> > 
> > Only if you attempt to sell it ...
> 
> No.  The patent law prohibits anyone from "making, using, or selling" 
> anything covered under the patent.  Selling it makes it more likely
> that the patent holder will come after you, as they have a greater
> chance of getting some money from you.
> 
> I am not a lawyer, I am sure someone here can explain all this in
> greater detail, or correct me if I'm wrong.

This is one of the sillier threads I've seen in a while. Is anyone here
arguing seriously that RFI shielding your equipment is a patented technology?

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Fri, 18 Dec 92 11:49:01 PST
To: cypherpunks@toad.com
Subject: Re: The Need for Positive Repuations
Message-ID: <9212181645.AA29793@maggie.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain



> From: tcmay@netcom.com (Timothy C. May)
> The longterm solution is to use "positive reputations" and not just
> "negative reputations" (as in Kill files). This is something Dean
> Tribble just talked about at our last physical meeting of the
> Cypherpunks ("Bay Area Branch" :-} ).
> 
> Think of like a credit rating. People _earn_ trust, they don't just
> get assigned a credit rating until they do something bad. 

Indeed, in the long run, when there are billions of people in the nets,
even UseNet newsgroups devoted to people who use musical instruments as
sex toys would have thousands of posts a day because given billions of
possible subscribers, finding a few tens of thousands with a particularly
obscure interest wouldn't be hard. Thus, in the long run, the nets will move
to "closed" newsgroups and mailing lists in which to be a subscriber one
will have to be explicitly subscribed to a list and will only be able to
read with one's private key and post by digitally signing messages. In such
an environment, anonymous abusers will simply be incapable of annoying people.

A weak version of this exists already in the Extropians mailing list, which
considers itself to be a closed list. The list is governed by a privately
produced legal code (its in some ways a test of anarchocapitalist legal theory),
and since the adoption of the code, we've had a reduction of flaming by
a large factor even though we've seen a three fold increase in list size.
The content is improving because people know that sanctions will be applied
for flaming and that they can actually be kicked off the list, and that being
kicked off is meaningful. In the long run, all serious discussion groups
will likely evolve in this direction, with the lists being closed to explicit
subscribers and with meaningful sanctions like ostracism being applied to 
people that behave in an antisocial manner. Such lists have little reason
to fear people hiding behind cloaks of anonymity. With digital signatures,
even the anonymous can develop meaningful reputations and can be sanctioned
for failing to live up to those reputations.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Derek Atkins <warlord@MIT.EDU>
Date: Fri, 18 Dec 92 08:55:19 PST
To: Marc Horowitz <marc@MIT.EDU>
Subject: Re: holiday travel: sign some keys!
In-Reply-To: <9212180907.AA07411@portnoy.MIT.EDU>
Message-ID: <9212181654.AA05651@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


I like the idea!  Anyways, being one of the people who has
cross-signed with marc, and hoping to increase our web of
trust....

I'll be in the NorthEast Ohio region for about 2 weeks, 
21Dec-4Jan, with a small stint in Brampton, Ontario over
New Years...  My Cleveland contact number is (216) 292-5845.
I don't have a contact number in CA, so you'll have to either
e-mail me by this weekend or get ahold of me in Cleveland.

Like marc, I like to sign keys out-of-band.  I'll have my
key fingerprint for anyone who wants it.  

I hope to see some of you over the holiday season!

-derek




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Fri, 18 Dec 92 14:18:16 PST
To: cypherpunks@toad.com
Subject: The Wheel
Message-ID: <9211187247.AA724710372@jplpost.jpl.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain




          Has anyone built there own TEMPEST reciever/antenna
          equipment?  I have seen articles that say that you can
          use old television sets, and that you can build more
          advanced TEMPEST unit for a hundred dollars.  This seems
          akin to the carburator that will give you 200 mpg, and
          plans for a particle beam cannon in the back of some zines.

          If this is so cheap and easy or cheaper-quicker-better
          (NASA-Goldin-TQM propoganda), then why haven't we seen an
          article/articles on the construction of a TEMPEST reciever
          and the associated tuning/specs on such an item.

          Is it possible, or nothing more than snake oil?

          JPW




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Fri, 18 Dec 92 10:29:44 PST
To: deboni@diego.llnl.gov (Tom DeBoni)
Subject: Reputation Systems
In-Reply-To: <9212181748.AA03280@diego.llnl.gov>
Message-ID: <9212181828.AA25958@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> it's easier on the nerves, attitude, and karma to assume the best
> in those I interact with.

But you can not interact with everyone that that has the technical means to
post a message.  If you can now, somehow, (you can't do much else if you
want to keep up with 50MB per day), then in the near future you will not be
able to.

So, you need a way to pick who to interact with.  

> I think it's significant that there are really so
> few of us on the net who are actually insufferable and refuse to be shouted
> down to reasonable behavior by the civil rest of us. Those few who are will

If you are referring to the current state of the UseNet, then I suggest
that you keep in mind that until fairly recently the access was mostly
limited to people in universities, and research departments of hi-tech
corporations.  This is a highly selected group of people, and can not be
compared to the "general public".

As communications technology becomes cheaper, more widespread and
accessible to anyone that wants to, and eventually ubiquitous like the
telephone is now, the number of people that will be able to "interact" will
be much greater.

In general, I view this as a good thing.  Unfortunately, the ratio
of people that I would find _interesting_ or _usefule_ to "talk" to in
relation to the total number of people I _can_ talk to will decrease
dramatically.

> not be prevented from troubling us by the measures being advocated - positive
> reps, scores on 1-to-10 scales, etc. - any more than weapon makers are
> deterred by manufacturers of armor. someone who really wanted to could still

I don't think anyone intends to use reputation systems to prevent someone
from posting a message, instead as a means to easily filter the messages
you personally want to read.  

Or maybe even not filter, but as some suggested, _sort_.  So you would first
read (and reply to) the messages of people with a higher reputation for
writing informative articles, or participating in interesting discussions.  

To some extent, this already is already occurring.  If there are some
people that you remember from the past as interesting people to talk to,
you are more likely to read their messages.  

An automated system would let you benefit from other peoples' memories.

> groups with garbage? And if it ever becomes a problem, we'll just have to
> appoint a moderator, perhaps on a rotating basis, from among those of us who

Think of a reputation system as being a distributed moderator.

--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: jthomas@kolanut.mitre.org (Joe Thomas)
Date: Fri, 18 Dec 92 12:20:39 PST
To: cypherpunks@toad.com
Subject: Re: The Need for Positive Repuations
Message-ID: <9212182019.AA00438@kolanut>
MIME-Version: 1.0
Content-Type: text/plain


> From: tcmay@netcom.com (Timothy C. May)
> The longterm solution is to use "positive reputations" and not just
> "negative reputations" (as in Kill files). This is something Dean
> Tribble just talked about at our last physical meeting of the
> Cypherpunks ("Bay Area Branch" :-} ).
> 

> Think of like a credit rating. People _earn_ trust, they don't just
> get assigned a credit rating until they do something bad. 


>From: pmetzger@shearson.com (Perry E. Metzger)
>Indeed, in the long run, when there are billions of people in the  
>nets, even UseNet newsgroups devoted to people who use musical  
>instruments as sex toys would have thousands of posts a day because  
>given billions of possible subscribers, finding a few tens of  
>thousands with a particularly obscure interest wouldn't be hard.  
>Thus, in the long run, the nets will move to "closed" newsgroups and  
>mailing lists in which to be a subscriber one will have to be  
>explicitly subscribed to a list and will only be able to read with  
>one's private key and post by digitally signing messages. In such
>an environment, anonymous abusers will simply be incapable of  
>annoying people.

Yes, but there will still need to be a way for new people to join the  
lists, (and the net in general) before they've had a chance to "prove  
themselves."  Allowing all new id's to post to the whole group on a  
probationary basis is unacceptable;  as soon as someone proves  
obnoxious enough to kick off they could just start over with a new  
id.  The obvious answer is that a moderator will be necessary for all  
closed lists that require a positive rep for posting and that don't  
wish to be forever limited to their founding members.  After a few  
lucid posts passed by the moderator, an individual would gain enough  
of a reputation not to be filtered out any longer.

Of course, anyone who's heard Howard Stern fans invade political  
call-in shows will realize there's not much that can be done with  
those weird people who will spend a lot of time and energy to appear  
credible, only to annoy people.

Joe




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tcmay@netcom.com (Timothy C. May)
Date: Fri, 18 Dec 92 15:55:47 PST
To: cypherpunks@toad.com
Subject: Re: The Need for Positive Repuations
In-Reply-To: <9212182252.AA06643@tla>
Message-ID: <9212182354.AA14872@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Marc writes:

> Go read Ender's Game.  They had a seriously electronic society.  There
> were public message boards, and positive-reputation-based boards.
> Basically, if you demonstrated a clue on the public boards, then
> someone already reputable could recommend you for "membership" in the
> reputation-based boards.  One of the characters did so anonymously.
> She even got paid for writing editorials, etc.  Anybody could watch
> the proceeedings of the reputeable boards.  In time, she was competing
> in debates with major politicians, et. al.  Sci-fi?  or Reality?  I
> believe we could move from the former to the latter.  (And I just
> avoided any sort of spoiler about the plot ;-)

Exactly! "Ender's Game," by Orson Scott Card, and "True Names," by
Vernor Vinge, are the two books I've been recommending since I coined
the term "crypto anarchy" in 1987. I held these books up in a couple
of talks I gave at BayCon (SF convention) and the Hackers Conference
and said "Read these books!"

A couple of folks have said that newcomers will never be listened to,
will never "get in" to positive reputation systems. This simply isn't
true, even with today's "manual" reputation management systems. On the
two main lists I subscribe to, this list and the Extropians list (send
request to Extropians-request@gnu.ai,mit.edu if interested in future
stuff, anarchocapitalism, nanotech, cryonics, etc....about a dozen
folks on this list are also on Extropians, I would guess), newcomers
start making posts and gradually the list gets to know their name,
what to expect of them, etc. This is their "rep." Serious flamers or
abusers see their rep torn down.

(A list I just joined is the Pynchon list...actually, one of them saw
my "W.A.S.T.E. line in my .sig and _invited_ me to join. As a newcomer
to that list, I have no reputation. What I say and how reasonably I
say it will establish my rep. This is as it should be.)

If people want to see the posts and comments of newcomers, even those
without extensive history on the list or glowing reps, then they will
likely set their "agents" to allow the new stuff through. Lots of
variations are possible and will be tried.

Think about positive reputations and you'll see them in action all
around you...where you shop, what you read, who you associate with,
etc. The Net will ultimately be no different.

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: habs@acf3.NYU.EDU (Harry A. B. Shapiro)
Date: Fri, 18 Dec 92 12:54:54 PST
To: cypherpunks@toad.com
Subject: Re: The Need for Positive Repuations
In-Reply-To: <9212182019.AA00438@kolanut>
Message-ID: <9212182054.AA11836@acf3.NYU.EDU>
MIME-Version: 1.0
Content-Type: text/plain


A conscious being, Joe Thomas, wrote in a previous message:
> Yes, but there will still need to be a way for new people to join the  
> lists, (and the net in general) before they've had a chance to "prove  
> themselves." 

There will always be the Sear credit cards of news groups. Those
that will let almost anyone in - just so they can prove themselves.


-- 
habs@acf3.NYU.EDU
habs@gnu.ai.mit.edu
habs@well.sf.ca.us
habs@panix.com



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Fri, 18 Dec 92 17:35:03 PST
To: cypherpunks@toad.com
Subject: reputations talk notes
Message-ID: <9212190048.AA04870@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


These are the notes from my talk at the last meeting.  
They may only be parsable by people who saw the talk, 
but I'm interested in all comments.

Thanks to Mark Miller and Eric Drexler who helped me put
together these notes the first time.

The need for reputations:
	single Prisoner's Dilemna incentive for defecting
	iterated Prisoner's dilemna incentive for cooperating
	reps put each person in an iterated situation with the group
	better reputations reduce reputation float (see below)

Spreading reputations makes them better at encouraging cooperation

Uses of reputations:
	sorting
	filtering - this is just bad sorting
	collateral - for business and important trust issues
	let me add that reputation appication is largely on the receiving side

Negative reputations:
	don't work with anonymity because you just make another identity
	don't spread for psychological and legal reasons
		many people won't reveal negative opinions about others people
	primarily support filtering and collateral

Positive reputations:
	are safer to reveal and spread
	allow sorting
	can handle anonymous pseudonyms

Anonymity:
	reduces perceived and actual accountability
	breaks many of our trained intutions for trusting others
	implicit but unrevealed assets aren't at risk
	trade names are examples of non-anon. pseudonyms

Reputations systems for sorting mail are less of an issues than
reputations systems for actual business because there is less at risk.
Gaming of a reputation system depends on how much is at risk.

Brilliant Pennies: randomly generated reputations
	the con game:
		start with 1000 pennies
		flip them every day.  head the stock market goes up, tails it goes down
		throw out pennies that 'guessed' wrong
		at the end of ten days you have a penny with a 'reputation' 
			for predicting the stock market
		sell the penny anonymously :-)
	inconsistent positive reputations are better than perfect reputations
		can explain away first several mistakes

Assets that support an identity
	recoverable assets
		anything that can be recovered in the even of a defection
			bank accounts, goods, factories, etc.
		pseudonyms typically won't have recoverable assets
		pseudonyms could keep recoverable assets in a non-anonymous escrow
		can be anonymously and privately committed to more than one party in the
			event of a defection, so value can't properly be assessed
	unrecoverable assets
		Sunk costs
			time, money spent building a reputation
			solves the Brilliant Penny problem: 
				random rep requires huge investment
				a 30day coin-flipping rep requires more pennies than exist
			notarized money-destruction service:
				proves investment with no route for kickbacks to the investor
				demonstrates the comparative cost of running an anon. service
			our intuitions about sunk costs can be very wrong here
				we're used to sunk costs at least looking recoverable (liquidation)
				we're used to eventual personal accountability of decision maker
			sunk costs enable kill files again
				you can only afford so many pseudonyms
				this is relates to the Brilliant Penny solution
		reputation capital (perceived value of reputation)
			customer good will, market share, shelf space, customer mind-space, etc.
			priority settings in receivers's mail handlers (filters, sorters)
			future sales potential
			based on the net present value of the reputation
				perceived differently by different individuals (customers/producer)
				based on discount rate (subjective value of money now vs. money later?)
				perception of discount rate can change radically
					you are told you have 6 months to live

Reputation Float:
	latency between use of a reputation and the effect on the value of the reputation
		how long can you ride on past glory?
	this includes the amount of goods, etc. against which the reputation is collateral
		existing trade-names collateralize the quality of existing goods (i.e. cars)
	estimating reputation float is a public goods problem
		why should I reveal the goods I have outstanding if I can get the info anyway
	insurance (Idea Futures) doesn't help
		the anonymous could collect both from defaulting and from insurance
	our intuitions screw up at estimating this 
		we're not used to untraceable transactions

Miscellaneous:
	filtering/sorting reputations should be wrt to topics
		This generalizes to other criteria
		individuals have different levels of expertise in different areas
	synthesized reputations are reputations composed from multiple reputations
		chaining remailers composes their reputations for security
		voting among key providers composes their uncompromisability reputations




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: tribble@xanadu.com (E. Dean Tribble)
Date: Fri, 18 Dec 92 17:35:04 PST
To: cypherpunks@toad.com
Subject: reputations
Message-ID: <9212190101.AA04917@xanadu.xanadu.com>
MIME-Version: 1.0
Content-Type: text/plain


Since I have a reputation for talking about reputations....

You are already engaged in a positive reputation system.  Which email
lists are you on?  Which newsGroups do you bother with?  what TV shows
do you watch?  New instances of all of these pop up and succeed all
the time.

Negative reputation systems work very poorly.  Right now I receive
cypherpunks.  I used to receive Extropians (and will do so again
soon).  The volume can get horrific at times.  Consider all the stuff
that I'm not receiving (that I filtered out).  I don't see
sci.nanotech, sci.crypt, alt.pgp (?), libernet, alt.politics,
alt.sex.bondage, etc. because I haven't the bandwidth.

Ah, but if I could pick and choose among the entire available feed
rather than ignoring most of it just so I have a hope of filtering
down to a manageable mail load....

That's what positive filters are for.  There are lots of gems buried
in the crap of net-news (and remember that my gems may be your crap),
and I want a system that will find them for me.

I think the approach of reputation filtered mailing lists is a bad
one.  That reputation filtering process is simply a poor mechanism to
avail us all of the moderator's taste in email.  If we had a better
mechanism, then such a list is just alt.extropy or sci.crypt where
things are prioritized (using the positive prioritixing information of
such people who would otherwise be moderators) such that I see the
good stuff and ignore the bozoz (whomever they are).  Or in the more
likely case, I just see the creme de la creme of the good stuff
because that's all I have time for.

In such a system, one can think of a magazine as simply purchasing the
editor's priority information.

Paul Baclace built a genetic algorithm thing that would present
netnews from all groups in prioritized order.  As you gave it feedback
on how glad you were to receive each message, it didi pattern matching
on features of the messages to make better sorters.  This ends up
correlating author (anonymous or otherwise), subjet, topic, reply
chain, time of day, whatever seems relevant into the prioritization of
mail.  If those weight could be spread, combined with manually entered
filters ("I'm tired of politics..."), etc. you might actually be able
to spend less time on email/news getting more value from it.

dean




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: 2FTPHAVOC@kuhub.cc.ukans.edu
Date: Fri, 18 Dec 92 15:24:06 PST
To: cypherpunks@toad.com
Subject: Patently false rumor
Message-ID: <01GSGW2OK9420056TH@KUHUB.CC.UKANS.EDU>
MIME-Version: 1.0
Content-Type: text/plain


I just finished reading the Mondo 2k article on cypherpunks.  I was hoping to find out some more info on !encrytption software.  All rumors are built on a grain of truth, aren't they?




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc Horowitz <marc@MIT.EDU>
Date: Fri, 18 Dec 92 14:53:18 PST
To: cypherpunks@toad.com
Subject: Re: The Need for Positive Repuations
In-Reply-To: <9212182054.AA11836@acf3.NYU.EDU>
Message-ID: <9212182252.AA06643@tla>
MIME-Version: 1.0
Content-Type: text/plain


Go read Ender's Game.  They had a seriously electronic society.  There
were public message boards, and positive-reputation-based boards.
Basically, if you demonstrated a clue on the public boards, then
someone already reputable could recommend you for "membership" in the
reputation-based boards.  One of the characters did so anonymously.
She even got paid for writing editorials, etc.  Anybody could watch
the proceeedings of the reputeable boards.  In time, she was competing
in debates with major politicians, et. al.  Sci-fi?  or Reality?  I
believe we could move from the former to the latter.  (And I just
avoided any sort of spoiler about the plot ;-)

Imagine a system where spaf distributed the public key of the
moderator(s) of a moderated newgroup.  News servers would make sure
that the message was signed by the moderator, or that the poster
included some sort of certificate, signed by the moderator, indicating
that he could post without having to go through the moderator first.
Expirations and/or revocation lists would be needed to do things
right, but these are problems with fairly good solutions.

		Marc




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Fri, 18 Dec 92 01:16:11 PST
To: cypherpunks@toad.com
Subject: TEMPEST/Van Eyck data
Message-ID: <9212180915.AA16502@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


From: strat@intercon.com (Bob Stratton)

>It's weird stuff, and some people would rather not have the world
>learning how to do this. In fact, Van Eck's original article is known
>to have some deliberate misinformation in it, as the author didn't
>want to make it "too easy" to learn how to do this kind of ELINT.

Ever realised that some things come along that just tickle your curiosity
nerve and you wont let go until your satisfied? Im sure there are
individuals and organisations out there that would love an excuse to shut
down lists of this type, especially considering the type of information and
the implications in the not too distant future if people start implementing
half the concepts that are presented here.

I would like to see indepth technical information, or at least pointers to
said information presented here. Does anyone know of mailing lists out there
that concentrate on levels of computer emissions and methods of diminishing
them to negliable amounts?

Where would one obtain copies of articles on the subject? I have saved the
article posted by treason@gnu as it does contain a lot of references which
give one something to go on. I commend him for posting it for it's
informational content. It wasnt his fault it may have contained obselete or
inaccurate information.

So, anyone have lists of books, periodicals, email lists or papers that 
discuss the topic of computer RF emissions and how to protect a machine
*AND* monitor the levels of others? 

Mark
mark@coombs.anu.edu.au

P.S. That NASA guy had better watch for list members waiting for the postie
	 so they can collect the goodies before he can :)




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Sat, 19 Dec 92 08:09:32 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Remailer Policies
Message-ID: <NcD2VB2w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


I would like to expand on Hal's suggestion that remailer operators
post their policies on a)keeping logs and b) divulging same.
 
Hal says he keeps logs "for a few days" and might divulge logs of
"really vicious, racially or sexually harrassing" messages.
 
Presumably this would also cover anonymous threatening messages,
blackmail, etc.
 
We've already discussed use of PGP by pedophiles to encrypt
incriminating diaries.  It gets better.  PGP and remailers can
be used to encrypt and ship "kiddy porn" GIF files. Even private
possession of such material is a serious crime in the USA. A chain
of anonymous and encrypted remailers could be used to drop kiddy porn
into newsgroups like
 
  alt.sex.pictures
 
I'm sure that would create quite a stir!
 
Perhaps Duncan or another attorney would like to comment on legal
liability of remailers in these kinds of situations. I don't think
there's currently any law on what records remailers would have to
keep; if you didn't have them, you couldn't give them up.
 
If this becomes a problem, expect legislation regulating or even
outright banning remailers. However, if remailer code has spread
over many national boundaries, such legislation may not be effective.
 
By the way, no-one has yet responded to my request to add features
to Eric's remailer to 1)remove the "sig" after "--" and 2)Anonymously
post to newsgroups available at the remailer site.  Both these
features are present in the Australian remailer at Pax. Unfortunately
that remailer seems less secure than Eric's in that it keeps more or
less permanent records of its users at the remailer site and it
doesn't seem to be able to chain to other remailers.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: peter honeyman <honey@homey.citi.umich.edu>
Date: Sat, 19 Dec 92 05:56:01 PST
To: yanek@novavax.nova.edu (Yanek Martinson)
Subject: Re: Reputation Systems
In-Reply-To: <9212181828.AA25958@novavax.nova.edu>
Message-ID: <9212191355.AA24847@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


i should think that a middle ground would be suitable, in which
people keep a hot list and an "other" list, with perhaps a kill
list as well.

	peter




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sat, 19 Dec 92 10:30:47 PST
To: honey@citi.umich.edu (peter honeyman)
Subject: Re: positive rep
In-Reply-To: <9212191759.AA01309@novavax.nova.edu>
Message-ID: <9212191829.AA02189@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> but how do you know who to add to the positive rep list?  take netnews,
> e.g.  i generally scan a group for names i know (+ rep), then read

For example, all mail/news reader software would have a function where
after reading the article you could press a key to indicate you found
the article useful/informative/interesting.  What it would do is send
the person a "certificate", which in essence says "I recommend reading
messages by this person", signed cryptographically with your signature.

These certificates could be appended to messages by that person, or 
posted to some special newsgroup just for that purpose (similar to
"control"), or distributed through some other means.  

If several people to whom you have assigned high credibility recommend
messages by a person, then your news software would automatically sort
his messages to appear higher in the list before other people's messages,
and also that person's recommendations would have a higher weight in
computing other people's sort values.

All this pre-supposes widespread use of authenticated messages, so 
someone could not forge himself some certificates from well-known
people.  Also, it would not allow a J. Random to forge a post that
appears to be from a person with high reputation.

The technology for such communication exists now (PGP, MD5, RSAREF, etc)
it is just not integrated into most news/mail software.

Unlike negative reputations, positive reputations are immune to
subversion by creating many anonymous or pseudonymous identities.

You might imagine someone creating two hundred "people" and have them
all send him their "certificates". 

But this would not work, since no-one has recommended these people, their
certificate would carry no weight whatsoever.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu (John Gilmore)
Date: Sat, 19 Dec 92 14:46:06 PST
To: cypherpunks@toad.com, gnu
Subject: TEMPEST
Message-ID: <9212192246.AA05562@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> There are plenty of other government conspiracies to focus on ! This one
> seems a bit lame.

Our government should not be our opponent when we try to find out how
to provide high levels of privacy for ourselves, our computers, and
our communications.

Ignoring that, yes, TEMPEST doesn't look like a deep dark conspiracy.
It's legal to shield your equipment and probably legal to export it (if
you didn't use the classified TEMPEST specifications in building it,
but reverse engineered them yourself).  The government is not our enemy
here (like it *is* our enemy in the drug war), but it isn't our friend
either.

	John Gilmore




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 19 Dec 92 16:52:59 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Remailers.
Message-ID: <921220004532_74076.1041_DHJ42-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Responding to Edgar Swank's message:

> We've already discussed use of PGP by pedophiles to encrypt
> incriminating diaries.  It gets better.  PGP and remailers can
> be used to encrypt and ship "kiddy porn" GIF files. Even private
> possession of such material is a serious crime in the USA. A chain
> of anonymous and encrypted remailers could be used to drop kiddy porn
> into newsgroups like
>  
>   alt.sex.pictures
>  
> I'm sure that would create quite a stir!

This could easily happen soon, as news of these remailers spreads.
There's been talk on the net about a student at an Ivy League college
who is being investigated by the FBI for allegedly posting illegal
images containing child pornagraphy.  Once people find out about
anonymous remailers, especially ours with their chaining capabilities
and encryption, they will realize that such posts can be made with
almost total safety.  Presumably this may increase the number of
people who would attempt it.

> Perhaps Duncan or another attorney would like to comment on legal
> liability of remailers in these kinds of situations. I don't think
> there's currently any law on what records remailers would have to
> keep; if you didn't have them, you couldn't give them up.
>  
> If this becomes a problem, expect legislation regulating or even
> outright banning remailers. However, if remailer code has spread
> over many national boundaries, such legislation may not be effective.

My guess is that it will not be feasible to ban remailers, since it
would be hard to draw the line between completely automated remailers,
and simple manual forwarding of a message that someone sent you, which
happens all the time and can hardly be made illegal.

I suspect that instead the approach would be to claim that remailer
operators are responsible for the material their remailers produce,
regardless of its original source.  So if child porn comes out, I
am guilty of sending child porn.  I can argue that my remailer was
automatic and that I shouldn't be held responsible for what comes out
of it, but my guess is that this argument will be rejected on the
grounds of personal responsibility, and because no one forces me to
run a remailer which sends out anything that comes in to it.

Such a policy would be a plausible extension of current Internet
policies, IMO.  RFC 822, the document which describes the format of
Internet mail message, in session 4.4.2 discusses the "Sender:" field,
and says, "Since the critical function served by the 'Sender' field
is identification of the agent responsible for sending mail and
since computer programs cannot be held accountable for their behavior,
it is strongly recommended that when a computer program generates a
message, the HUMAN who is responsible for that program be referenced
as part of the 'Sender' field mailbox specification."  [Capitalization
in the original.]  The need for a person to take responsibility for
each piece of mail that is sent would tend to lead to the policy
I mentioned.

With such a policy in place, if enforced by law, I don't think people
would run remailers in this country because of the legal risks.  There
would still be the international remailers, though.

> By the way, no-one has yet responded to my request to add features
> to Eric's remailer to 1)remove the "sig" after "--" and 2)Anonymously
> post to newsgroups available at the remailer site.  Both these
> features are present in the Australian remailer at Pax. Unfortunately
> that remailer seems less secure than Eric's in that it keeps more or
> less permanent records of its users at the remailer site and it
> doesn't seem to be able to chain to other remailers.
> 
> --
> edgar@spectrx.saigon.com (Edgar W. Swank)
> SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca

It should be possible to chain from Pax to our remailers, getting the
best features of both.  Pax could be the first remailer in the chain,
stripping the sig.  The message could then go through our remailers,
providing non-traced security, at least if you can find someone who
does not keep logs.

Anonymous posting can be done already.  Anyone can post to most newsgroups
by sending mail to certain addresses.  One such system is at Berkeley.
Send to, e.g., sci-crypt@ucbvax.berkeley.edu to post to sci.crypt.  There
is another such system running in Austin, TX, I believe, but I don't
have the corresponding net address handy.  So this capability is already
provided by our (or anyone's) remailers.

One reason I haven't looked at stripping the .sig is due to an email
discussion I had about a month ago with Eric Hughes.  Eric strongly
felt that message bodies should be preserved as much as possible by the
remailers, in accordance with the general principle of Internet mail
forwarding.  Too much mangling is done already by mail gateways,
and adding more changes might be harmful.  Obviously, the remailers can't
avoid doing some processing of the message body, what with the "::"
pasting tokens and PGP decryption, but Eric felt that unnecessary
changes should be minimized.  I know Eric is working on some new
remailer concepts so I want to defer to him on this issue for now.

Hal Finney
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzOXf6gTA69YIUw3AQEvQQQArHXSwwrkQ3mSGOD60ZBV/p1R9RONqv2x
S64iJjdJB43G2nxLHB2t9xXAKSdCT00shEtil8LWu20XW0rWXqmMXyYudtt3qf3t
2arqlvxdGXlPt3eISFJ97U6jaI1EhswPg29fjuXMMaKv5OO/gBKp1i9Cig7suZDt
EkUDJihLQxc=
=q6zH
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Hollander <hh@soda.berkeley.edu>
Date: Sun, 20 Dec 92 00:02:57 PST
To: dclunie@pax.tpa.com.au (David Clunie)
Subject: Re: Remailer Policies
In-Reply-To: <9212192250.AA01396@britt>
Message-ID: <9212200800.AA20904@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain




>The anonymous mailing system at pax has the following policy:
>
>  - A log of activities of the remailing software is maintained when
>    debugging is in progress (often) which could be used to correlate
>    real identities with aliases - this is no more or less information
>    than is available in the alias database which is not visible to
>    anyone except the root user. Message-id's are NOT stored in this log,
>    and the contents of messages and posts are NOT stored anywhere, nor
>    are they scrutinized by me or anyone else. I don't care and I don't
>    want to know. If someone does something unreasonable and I get
>    complaints then I could lock out a particular source of mail if
>    I didn't get a good explanation, but I am not going to go reading
>    other peoples mail in order to censor it !

I keep logs on content and origin on my three remailers.  I do read the
logs.  However, I would not censor any transmissions.  I would stop
accepting mail from a site given enough reasonable complaints.

>  - Under no circumstance short of being arrested and/or the equipment
>    commandeered by someone else will the alias database be divulged
>    or the contents or routes of messages deliberately intercepted.

Dido for me.  I would make an attempt to destroy all of my data if an
attempt were made to take the equipment or access the data by a government
or other agency.

e




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "DrZaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Sun, 20 Dec 92 09:54:49 PST
To: CypherPunks@Toad.Com
Subject: Avoiding snags in the Law : Remailers.
Message-ID: <24020.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


In Message 19 Dec 92 19:45:33 EST,
  Hal <CompuServe.COM!74076.1041@netcomsv.netcom.com> writes:

>I suspect that instead the approach would be to claim that remailer
>operators are responsible for the material their remailers produce,
>regardless of its original source.

>Such a policy would be a plausible extension of current Internet
>policies, IMO.  RFC 822, the document which describes the format of
>Internet mail message, in session 4.4.2 discusses the "Sender:" field,
>and says, "Since the critical function served by the 'Sender' field
>is identification of the agent responsible for sending mail and
>since computer programs cannot be held accountable for their behavior,
>it is strongly recommended that when a computer program generates a
>message, the HUMAN who is responsible for that program be referenced
>as part of the 'Sender' field mailbox specification."  [Capitalization
>in the original.]  The need for a person to take responsibility for
>each piece of mail that is sent would tend to lead to the policy
>I mentioned.
>

     Perhaps the solution to this is to run encrypted remailers,
anonymously.  The remailer could either run on it's own, or under
instructions by an anonymous source [i.e PGPed instructions and software
updates signed by the owner who has created a second key for his identity
of remailer operator [Let's call him Oz].

Example:

         Joe creates an account on a random system, installing the nessicary
         software to run a PGP remailer.  This software would be modified to
         accept instructions from a specific anonymous identity, for which
         Joe creates one, leaving the public key with the remailer.  The
         remailer also has it's own key pair to decrypt and forward messages
         [of course].

         People could now route their messages through Joe's remailer to
         anywhere they wish.  The remailer should be set up to NOT keeps
         logs, except errors.

         Now Joe decides he wants to update his remailer with the latest
         scripts.  He mails te scripts [thru various remailers], encrpyted
         with the remailers key and signed by Oz's key.  The remailer
         decrypts the mail, verifies that it belongs to Oz, and updates
         itself.

In this way no person can be held responsible for mail passing thru it's
remailer.  The only way to stop such a remailer would be to downright shut
it down, or to communicate to Oz via the remailer [the scripts would allow
Oz to pick up any mail left directly to the remailer withour a forwarding
header -- of course it would reroute the messages, encrypted, thru various
other well-known remailers].

TTFN!

DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Sun, 20 Dec 92 05:45:43 PST
To: hh@soda.berkeley.edu (Eric Hollander)
Subject: Destroying Data (Re: Remailer Policies)
In-Reply-To: <9212200800.AA20904@soda.berkeley.edu>
Message-ID: <9212201344.AA26203@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> logs.  However, I would not censor any transmissions.  I would stop
> accepting mail from a site given enough reasonable complaints.

That would not help in the least.  The person can still send mail 
through your system, they would just not use you as the first hop.
 
> Dido for me.  I would make an attempt to destroy all of my data if an
> attempt were made to take the equipment or access the data by a government

Make sure you don't think 'rm -rf /remailer-logs' actually destroys data.
It merely de-allocates the i-nodes.  You need to know which physical
device the filesystem is on, (let's call id /hdxxx) and then do
'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data
on that partition.  For that reason it may be preferable to keep all
such information opn a filesystem of their own, so you don't have to
destroy much other data along with it.

If you use swapping or paging, you need to clear out those devices
too, and then turn the machine off to remove all data in RAM.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dclunie@pax.tpa.com.AU (David Clunie)
Date: Sat, 19 Dec 92 14:50:47 PST
To: cypherpunks@toad.com
Subject: Re: Remailer Policies
Message-ID: <9212192250.AA01396@britt>
MIME-Version: 1.0
Content-Type: text/plain


> I would like to expand on Hal's suggestion that remailer operators
> post their policies on a)keeping logs and b) divulging same.
>  

The anonymous mailing system at pax has the following policy:

  - A log of activities of the remailing software is maintained when
    debugging is in progress (often) which could be used to correlate
    real identities with aliases - this is no more or less information
    than is available in the alias database which is not visible to
    anyone except the root user. Message-id's are NOT stored in this log,
    and the contents of messages and posts are NOT stored anywhere, nor
    are they scrutinized by me or anyone else. I don't care and I don't
    want to know. If someone does something unreasonable and I get
    complaints then I could lock out a particular source of mail if
    I didn't get a good explanation, but I am not going to go reading
    other peoples mail in order to censor it !

  - Under no circumstance short of being arrested and/or the equipment
    commandeered by someone else will the alias database be divulged
    or the contents or routes of messages deliberately intercepted.

david





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: bart@netcom.com (Harry Bartholomew)
Date: Sun, 20 Dec 92 09:53:45 PST
To: cypherpunks@toad.com
Subject: Re: Destroying Data
Message-ID: <9212201752.AA24549@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


	In audio recording which uses magnetic media similar to disks
	the only way to thoroughly erase a tape is with a so-called
	bulk eraser. This applies a very strong a.c. magnetic field
	and then is gradually withdrawn from the tape to allow the 
	residual magnetism to "follow the hysteresis curve" down to 
	zero. This would be difficult to apply to disks except floppies.

	Consider also the technique used in the Norton Utilities
	program "Diskwipe" which takes a /g switch which "Follows
	certain government rules for wiping". I can't find the manual
	but I think it specifies how many repetitions are used and
	different values to write in each. 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Sun, 20 Dec 92 03:25:01 PST
To: cypherpunks@toad.com
Subject: Remailers and liability
Message-ID: <1992Dec20.105340.11707@extropia.wimsey.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain


Here is a post which is somewhat relevant:

>Newsgroups: alt.censorship,news.admin.policy,comp.org.eff.talk
>From: nagle@netcom.com (John Nagle)
>Subject: Appeals court declares child pornography law unconstitutional
>Message-ID: <1992Dec17.232618.19727@netcom.com>
Summary: New decision by Ninth Circuit may affect BBS operators
>Keywords: law pornography
>Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
>Date: Thu, 17 Dec 1992 23:26:18 GMT

     The Ninth U.S. Circuit Court of Appeals ruled, in US vs X-Citement
Video Inc., (CA No. 89-50556), that the sections of the Protection of
Children Against Sexual Exploitation Act of 1977 that deal with 
distribution, transportation, and receipt of sexually explicit 
materials are invalid on First Amendment grounds.  The court let stand the 
prohibition on the production of child pornography.

     This ruling needs to be looked at more closely, but it may help to
remove sysop worries about someone posting such material on their system
without their knowledge, or about network nodes being liable for 
material passing through them.  This is a step forward, because it was
one of the very few real legal risks a US sysop had to face, and now
it appears to be dead. Do the lawyers out there agree with this analysis?

     Producing child pornography remains illegal, which is reasonable.

					John Nagle


Source: Wall Street Journal, 17DEC92, p. B10 (Western edition)






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: peter honeyman <honey@citi.umich.edu>
Date: Sun, 20 Dec 92 07:56:42 PST
To: yanek@novavax.nova.edu (Yanek Martinson)
Subject: Re: Destroying Data (Re: Remailer Policies)
In-Reply-To: <9212201344.AA26203@novavax.nova.edu>
Message-ID: <9212201556.AA22792@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> Make sure you don't think 'rm -rf /remailer-logs' actually destroys data.
> It merely de-allocates the i-nodes.  You need to know which physical
> device the filesystem is on, (let's call id /hdxxx) and then do
> 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data
> on that partition.  

not quite.  you need something like

  dd if=/dev/null of=/dev/xxx bs=verybig conv=sync

this will zero out every block on the disk.  but this is overkill --
why not just apply this technique to the individual logs, zeroing
out their data blocks?

	peter

ps:  is it certain that zeroing out the data blocks thoroughly destroys
the data?  i've heard that a "shadow" of some sort may remain.





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
Date: Sun, 20 Dec 92 20:56:59 PST
To: cypherpunks@toad.com
Subject: DES source for the HP48SX calculator.
Message-ID: <9212210240.AA00086@orchard.medford.ma.us>
MIME-Version: 1.0
Content-Type: text/plain


I have implemented a version of the core of the DES algorithm for the
HP 48SX calculator; I mentioned this in passing on this list a couple
of weeks ago.  Anyhow, in the general cypherpunks spirit of things,
I'm willing to share this code...

Note that this only ECB-mode encryption and key schedule computation,
and not decryption.  Both operations take about 12 seconds.. mostly
because they're written in user RPL rather than system RPL or machine
code.

If the person at Berkeley who maintains the cypherpunks FTP archive
wants to get in touch with me, I'd be happy to contribute this file to
the archive; also, I'll mail it to anyone with a US or Canadian email
return address.

					- Bill




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hkhenson@cup.portal.com
Date: Mon, 21 Dec 92 10:21:48 PST
To: cypherpunks@toad.com
Subject: Re: Remailer Policies
Message-ID: <9212210959.1.29952@cup.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


Re logs and trying to destroy them when the cops are beating down your
door, wouldn't it be a lot better to keep them encrypted?  Keith




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bruce F. Webster <pages!bwebster@uunet.UU.NET>
Date: Mon, 21 Dec 92 11:30:02 PST
To: cypherpunks@toad.com
Subject: PKP/RSA comments on PGP legality
Message-ID: <9212211904.AA15552@pages.com>
MIME-Version: 1.0
Content-Type: text/plain


(Cross-posted with permission of Eben Moglen):

Newsgroups: sci.crypt,alt.security.pgp
From: em21@cunixf.cc.columbia.edu (Eben Moglen)
Subject:  Re: PKP/RSA comments on PGP legality
Message-ID: <1992Dec17.150409.17696@news.columbia.edu>
Date: Thu, 17 Dec 1992 15:04:09 GMT

I have been following with interest, and distress, the conversation
about legal risks in using PGP set off by Carl Ellison's posting of
a document said to reflect the legal position of PKP.  Perhaps a
Columbia Law professor's views on these questions may be helpful.   
I'm going to discuss the realities of the situation, without jargon,
rather than the legal technicalities.  Those who want to discuss the
legal detail should feel free to contact me, but for legal advice I
usually get paid.

PKP says that any user of PGP is "inducing" infringement.  Here's the
reality of the situation.  PKP is the licensee of a presumptively
valid US patent, which it claims PGP 2.1 infringes.  If the patent is
valid, and PGP infringes, every user is not just inducing
infringement--he/she/it is infringing the patent.  This is not a
crime; it's a civil wrong, for which, as the PKP statement says,
damages are available at law.  But this is true every time a
manufacturer sells or distributes an infringing article.  As you may
recall, for example, an inventor recently won an enormous damages
judgment against a major US auto company for infringing his patent  
for intermittent windshield wipers.  Theoretically, under the patent  
law, he could instead have notified all Ford buyers in the past  
decade that they were personally infringing his patent.  But it is  
grossly impracticable to do that, and a suit against the manufacturer
accomplishes exactly the same result, since the total amount of the
damages available is the same either way, while the litigation cost  
is not.  PKP can test the validity of its patent and recover its  
damages, if any, in a suit against the developers and distributors of  
PGP, if it cares to.  Without any knowledge of their thinking, I  
predict the partners won't want to do that.  It would be expensive,  
the damages to be recovered would be slight or none, and they would  
risk having the only patent anywhere in the world protecting their  
technology declared invalid.  But in any event, it is virtually  
unheard-of to sue individual end-use consumers of allegedly  
infringing technology.  If PKP's investors had $100 million or so  
they wanted to waste in litigation anything could happen, but they  
don't, and it won't.

In any event, in such a situation a lawyer certainly might advise her
client to wait for the patent-holder to assert his rights directly. 

When PKP sends you a personal letter claiming that you are infringing
its patent, and asking you to take out a license, you can decide what
you want to do about it.  In the meanwhile, the patent claim against
end users is mostly, probably entirely, just noise.

The Munitions Act bluster contained in the post is not even that
important.  It's just ridiculous.  Others have said some of the most
important things well, so I'll be brief.  First, even if PKP believes
its own arguments interpreting the ITARs, PKP doesn't have squat to  
do with ITAR enforcement.  This is a question addressed to the  
discretion of the Treasury, the Department of Justice, and local  
United States Attorneys.  ITAR enforcement against distributors of  
PGP would require a decision by all those agencies that the  
highest-priority Munitions Act enforcement problem at some future  
moment is the prohibition of IMPORTATION of a CONSUMER SOFTWARE  
PRODUCT embodying TECHNICAL INFORMATION IN THE PUBLIC DOMAIN.  I  
challenge PKP, or anyone else, to show any past example of such an  
approach to ITAR enforcement by any Administration.  I cannot myself  
imagine any United States Attorney's office wanting to bring such a  
case, which is of nightmarish complexity, would be politically  
unpopular, and does nothing whatever to stem the global arms trade or  
increase the national security of the US.  I very much doubt that PKP  
really believes that the domestic circulation of PGP violates the  
ITARs, since PKP itself terms as "unfortunate" the application of the  
Munitions Act to cryptographic technology.  But even if that's really  
what PKP or its officers think, so what?  The chances that the United  
States Government will ever agree, and put weight behind agreement,  
are within fuzz of zero.

UseNet serves many social purposes.  One, apparently, is the no-cost
distribution of negative advertising and legal chest-pounding,
intended to frighten people away from experimentation with a piece of
interesting freeware.  Myself, I would just put the PKP temper  
tantrum in the bitbucket.  But since other people have taken it  
seriously (much more seriously than it deserves) I thought a few more  
sober comments might be warranted.
_____________________________________________________________________
Fiat Justitia,         "Quoi que vous fassiez, ecrasez l'infame,
ruat Coelum.                           et aimez qui vous aime."
Eben Moglen                       voice: 212-854-8382
Professor of Law & Legal History    fax: 212-854-7946          
Columbia Law School, 435 West 116th Street, NYC 10027           
moglen@lawmail.columbia.edu
-- 





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wcs@anchor.ho.att.com (Bill Stewart)
Date: Mon, 21 Dec 92 08:11:21 PST
To: cypherpunks@toad.com
Subject: Re: Destroying Data (Re: Remailer Policies)
Message-ID: <9212211610.AA21587@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text


Yanek points out that "rm" doesn't destroy data on disks, just inodes,
and that you have to overwrite the data to destroy it.  However,
he suggests that you do this by
> 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all
as well as overwriting swap space and powering off RAM.  
Won't work, and it's the hard way to do it: 
cat /dev/null produces zero bytes of output (there's a /dev/zero on
some systems which produces lots of bytes of zeros.)

If you're dealing with amateurs (i.e. local cops or maybe FBI, but not NSA/KGB,
who can take the disk apart and use fancy magnetic techniques),
you can get away with overwriting the data once with zeros or other stuff;
a simple approach is to create a file large enough to fill all the
unallocated space on the disk (either using /dev/zero or writing your own);
be sure to be root so you get the last 10% of a BSD file system.
For professionals, overwrite it once with 0s, once with 1s, and once with
some test pattern like Xs or /etc/termcap.  This still won't help
if there are bad blocks which the disk controller is mapping out
transparently to your system, of course, but amateurs can't read them.
Swap space is tougher - you'll need to look at how your kernel allocates it
to know how to fill it all up, or else zap it all after rebooting your system,
if this is practical.

The government's rules for handling, um, special data say that you either need
an officially approved software program, or an Official Big Magnet,
or else you need to physically destroy the magnetic media from the disk.
I don't like having Big Magnets near my lab, but sandblasting has a
real physicality to it, and floppy disks make this satisfying scrunch in a 
paper-shredder :-)  Needless to say, unless you're Ollie North, 
you shouldn't be shredding your data when the cops are busting you ...


			Bill Stewart, somewhere in New Jersey



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: jim@tadpole.com (Jim Thompson)
Date: Mon, 21 Dec 92 10:08:34 PST
To: cypherpunks@toad.com
Subject: Re: Destroying Data
Message-ID: <9212211807.AA25690@tadpole.tadpole.com>
MIME-Version: 1.0
Content-Type: text/plain


> 	Consider also the technique used in the Norton Utilities
> 	program "Diskwipe" which takes a /g switch which "Follows
> 	certain government rules for wiping". I can't find the manual
> 	but I think it specifies how many repetitions are used and
> 	different values to write in each. 

SunOS 4.X 'format/analyze/purge', (which was done at the request
of SunFed, for some Fed contract) uses 4 repetitions with patterns:

	0xaaaaaaaa	(10101010)
	0x55555555      (01010101)
	0xaaaaaaaa      (10101010)
	0xaaaaaaaa      (10101010)

Followed by a final pass with:

	0x40404040	(10000000)

Consider this secure if you want.  :-)  For Unix variants, one
might consider a 'patch' to libc that scribbled on the file passed
to the 'unlink()' system call before actually performing the syscall.

This will, of course, break Unix semantics because there is no way
to tell from userland that no other process is holding the file open,
so you'll scribble on the file prematurely.  I guess itrunc() is what
really need changing.

Jim





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Peter Shipley <shipley@tfs.COM>
Date: Mon, 21 Dec 92 17:07:02 PST
To: Phiber Optik <phiber@eff.org>
Subject: Re: Destroying Data (Re: Remailer Policies)
In-Reply-To: <199212220042.AA27413@eff.org>
Message-ID: <9212220106.AA06240@edev0.TFS>
MIME-Version: 1.0
Content-Type: text/plain



>> 
>> not quite.  you need something like
>> 
>>   dd if=/dev/null of=/dev/xxx bs=verybig conv=sync
>> 
>
>Unix weenies of old will recall "clri" to clear an inode.  If paranoia is in
>effect, try something like the following:
>
>ls -li remailer-log or whatever to get the i-node number,
>then 
>clri /dev/sdxx #_of_i-node

this will zero out the inode it also does NOT clear the data blocks
just the inode pointers to the data blocks. infact if you do this.

(this you *will* need to umnount and fsck your
system [or reboot if you did this to you root partition]).
in fact if you do this with out deleteing the file first you run a good
chance of crashing the system.


normaly I would say "do not try this at home" but then I would rather
you shot yourself in the foot at home (as opposed to shooting yourself
and who ever is on a public system)

I will post some C/Perl code that will work as a /bin/rm replacement in a
few days.


			-Pete




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Phiber Optik <phiber@eff.org>
Date: Mon, 21 Dec 92 16:43:07 PST
To: honey@citi.umich.edu (peter honeyman)
Subject: Re: Destroying Data (Re: Remailer Policies)
In-Reply-To: <9212201556.AA22792@toad.com>
Message-ID: <199212220042.AA27413@eff.org>
MIME-Version: 1.0
Content-Type: text/plain


> 
> > Make sure you don't think 'rm -rf /remailer-logs' actually destroys data.
> > It merely de-allocates the i-nodes.  You need to know which physical
> > device the filesystem is on, (let's call id /hdxxx) and then do
> > 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all data
> > on that partition.  
> 
> not quite.  you need something like
> 
>   dd if=/dev/null of=/dev/xxx bs=verybig conv=sync
> 

Unix weenies of old will recall "clri" to clear an inode.  If paranoia is in
effect, try something like the following:

ls -li remailer-log or whatever to get the i-node number,
then 
clri /dev/sdxx #_of_i-node

Of course, care should be taken to then unlink the file immediately, as if the
i-node number is reused on that filesystem, the old entry would still point
to that i-node, and removing the old file would remove the new one (an
inadvertent hard link).  Clri is in /usr/etc, and it's use is obviously
subjected to your permission of the device file (and the file itself), though
that's understood if you were going to use 'dd'.
Not everyone running a remailer will have permission (usually root) to write
directly to filesystem /dev files, so why not just write a little C program
to open the logfile and overwrite it to the end with NULL's?
Simple.
 




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Tue, 22 Dec 92 03:11:25 PST
To: cypherpunks@toad.com
Subject: My remailer and ARA's
Message-ID: <199212221104.AA20951@xtropia>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

My remailer does not support ARA's.  This is because the requirement
that incoming messages be completely encrypted with its key (any
portion which is not encrypted in this way is dropped).

In any case, the current scheme for ARA's is insecure.  This is
because people can send plaintext messages attached to the ARA.
This allows breaking anonymity by monitoring of the traffic from
all remailers and waiting until the message appears at one of
the outputs.

I will implement a more secure scheme.  The ARA will include
encryption instructions for each remailer.  Since each remailer
will be doing a transformation on the message, the attack above
will not be feasible.
- --
	Miron Cuperman <miron@extropia.wimsey.com>  | NeXTmail/mime ok
		       <miron@cs.sfu.ca>	    | Public key avail
	AMIX: MCuperman				    |
cybercomputingimmortalcryptolaissezfaire	    |

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzb2O5NxvvA36ONDAQG/0QP9GVjH8zjBakbYChxCECGRPb02UJvPC9bj
1lS6GF4KTc5Z9yBejYMSLu5E7lVamgcQFuaBFrSusLyl1oXDcJtCUF4TjxgLCAOi
dXnkbu+k5oB9vLqlZK3nTSmxAuddjrOxbg/AS6M+aIY7rtwkyfnTgj+7pq4pYj6P
/nIpWAB9NHE=
=/i5k
-----END PGP SIGNATURE-----




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: peter honeyman <honey@citi.umich.edu>
Date: Tue, 22 Dec 92 05:44:41 PST
To: Phiber Optik <phiber@eff.org>
Subject: Re: Destroying Data (Re: Remailer Policies)
In-Reply-To: <199212220042.AA27413@eff.org>
Message-ID: <9212221344.AA03085@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


> Unix weenies of old will recall "clri" to clear an inode. ...

clri destroys the file "handle" (the inode, thus the owner, mode,
length, pointers to data blocks, etc.) but not the contents of the
data blocks.  stringing them together is another story, but not
impossible if you know what you're looking for.

>                                 -- so why not just write a little C program
> to open the logfile and overwrite it to the end with NULL's?

u.w.o.o. often go to great lengths to avoid writing a few lines of c,
which, i suppose, is not so bad. 

but i agree with hkhenson that the best way to secure the remailer logs
is to encrypt them.

which raises a sticky point, since i don't see an easy way to do that
on a machine that you can't secure physically.

i'm familiar with the andrew environment (e.g., afs or the andrew
toolkit), which is more or less a kerberos environment, wherein secure
service providers run on physically secure machines.  this lets
sysadmins store cleartext passwords (in essence) on their local disks
to support reauthentication daemons (to refresh tokens for long-lived
jobs, since kerberos tickets time out).

this clearly would not achieve the objectives here.  the only option i
see is to enter a password at boot time (or when the remailer is started).

ick.

	peter




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 07:04:18 PST
To: cypherpunks@toad.com
Subject: Another pax-type remailer
Message-ID: <9212221503.AA26035@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


Forwarded message:
> Date: Tue, 22 Dec 92 15:24:12 +0200
> From: daemon@anon.penet.fi
> Message-Id: <9212221324.AA14827@anon.penet.fi>
> To: yanek@novavax.nova.edu
> Subject: Anonymous help.
> 
> 
>               The anon.penet.fi Anonymous Server
>               ==================================
> 
> Yes, another anonymous server. Why?  Well, several well-known servers have
> bitten the dust recently. And most of them have served only a very limited
> subset of newsgroups, and mail only to "registered", anonymous users. One
> quite successful attempt at solving this problem was the server running at
> godiva.nectar.cs.cmu.edu, written and operated by Karl Kleinpaste
> <Karl_Kleinpaste@cs.cmu.edu>. Karl's software has been posted to alt.sources.
> 
> Due to reasons too complicated to mention here I wanted to set up an
> anonymous server for the scandinavian user community. I contacted Karl, and
> got a pre-release copy of his software. As the version I got relied heavily
> on the advanced features of MMDFII, I had to modify it quite a bit. While
> hacking around, I removed the restriction of only supporting selected
> newsgroups. Within a week of startup, the server had been discovered by
> transatlantic users, and more recent stats show european users are definitely
> a minority.
> 
> So what does the anon server really do? Well, it provides a front for
> sending mail messages and posting news items anonymously. As you send your
> very first message to the server, it automatically allocates you an id of
> the form anNNN, and sends you a message containing the allocated id. This id
> is used in all your subsequent anon posts/mails. Any mail messages sent to
> your-id@anon.penet.fi gets redirected to your original, real address. Any
> reply is of course anonymized in the same way, so the server provides a
> double-blind. You will not know the true identity of any user, unless she
> chooses to reveal her identity explicitly.
> 
> In the anonymization process all headers indicating the true originator are
> removed, and an attempt is made to remove any automatically-included
> signatures, by looking for a line starting with two dashes (--), and zapping
> everything from there on. But if your signature starts with anything else,
> it's your own responsibility to remove it from your messages.
> 
> There are two basic ways to use the system. The easiest way is by sending a
> message to recipient@anon.penet.fi:
> 
> 	To: alt.sex.bestiality@anon.penet.fi
> 
> 	To: an9999@anon.penet.fi
> 
> 	To: help@anon.penet.fi
> 
> Of course, in the case of mailing to a known user, you have to use addresses of
> the form user%host.domain@anon.penet.fi, or the pretty obscure source addressing
> construct of @anon.penet.fi:user@host.domain. These constructs are not
> necessarily handled properly by all mail systems, so I strongly recommend the
> "X-Anon-To:" approach in these cases. This works by you sending a message to
> "anon@anon.penet.fi", including a X-Anon-To: header line containing the desired
> recipient. But this really has to be a field in the message header, before the
> first empty line in the message. So:
> 
> 	To: anon@anon.penet.fi
> 	X-Anon-To: alt.sex.needlework,rec.masturbation
> 
> 	To: anon@anon.penet.fi
> 	X-Anon-To: jack@host.bar.edu
> 
> Valid recipients in both cases are fully qualified user addresses in RFC-822
> format (user@host.domain), anon user id's (anNNN), newsgroup names
> (alt.sex.paperclips) or one of the "special" user names of ping, nick, help,
> admin and stat.
> 
> Sending to "ping" causes a short reply to be sent confirming (and
> allocating, if needed) your anon id. "nick" takes the contents of the
> Subject: header and installs it as your nickname. If you have a nickname, it
> appears in the From: header in the anonymized message along with your anon
> id. "help" returns this text, and stat gives some statistics about the
> system. Mail to "anon" goes directly to me unanonymized, and can be used to
> report problems. If you want to send mail to me anonymously, you can use
> "an0".
> 
> When crossposting to several newsgroups, you can list several newsgroups
> separated by commas (no whitespace) as recipients, but this only works using
> the X-Anon-To: header. References: headers do work, so they can (and should)
> be used to maintain reply threads.
> 
> Ah yes, please remember that the posting takes place at my local site, so you
> can only post to groups that are received at penet.fi. I get all "worldwide"
> groups, but various exotic local groups don't make it here. I have gotten
> a couple of comments about permitting anonymous postings to technical groups.
> I can only answer that I believe very firmly that it's not for me to dictate
> how other people ought to behave. Somebody might have a valid reason for
> posting anonymously to a group I might consider "technical". But remember
> anonymous postings are a privilege, and use them accordingly. I believe adult
> human beings can behave responsibly. Please don't let me down.
> 
> As the server was originally intended to be used by scandinavians, it
> includes support for various languages. The system makes an educated guess
> about your local language based on your top level domain. But it can
> misfire. Fortunately the server doesn't (yet) support urdu, swahili or
> basque... Ah, by the way, if you find it doesn't support your local
> language, and you want to volunteer to translate the message files, get in
> touch...
> 
> The user-id database is based on RFC822-ized forms of your originating
> address. This may cause problems for some users, either because their site
> is not properly registered in the name servers, resulting in
> non-deterministic addresses, or because their mail router doesn't hide the
> identity of individual workstations, resulting in different originating
> addresses depending on which workstation you mail from. Talk to your
> administrator. If that doesn't help, let me know, and I will make a manual
> re-mapping.
> 
> You might wonder about the sense of using a server out somewhere, as the
> song goes, "so close to Russia, so far from Japan". Well, the polar bears
> don't mind, and the ice on the cables don't bother too much :-)
> Well, in fact, as we live in a wonderfully networked world, the major delay
> is not going over the atlantic, but my local connection to the Finnish EUnet
> backbone, fuug.fi. Once you reach a well, connected host, such as
> uunet.uu.net, there's a direct SMTP connection to fuug.fi. My connection to
> fuug.fi is currently a polled connection over ISDN, soon to be upgraded to
> on-demand-SMTP/NNTP. But for now, expect a turn-around delay of 2-4 hours for
> trans-atlantic traffic.
> 
> Oh yes, then there's the question of confidentiality/security. The service
> runs on one of the 386 boxes in my back room at home, and the machine is not
> directly accessible from the internet. So the only one who can get to the
> database is myself. Well, if the police or the local Secret Service comes
> knocking at my door, with a court order to hand over the database, I might
> comply. But then I might, of course, accidentally delete the file instead of
> copying it... And maybe possibly there could be cases where, if somebody could
> come up with really hard evidence of activities such as blackmail, I could be
> persuaded...
> 
> Anyway, short of having everyone run a public-key cryptosystem such as PGP,
> there is no way to protect users from malicious administrators. You have to
> trust my personal integrity. Worse, you have to trust the administrators on
> every mail routing machine on the way, as the message only becomes anonymous
> once it reaches my machine. Malicious sysadmins and/or crackers could spy on
> SMTP mail channels, sendmail queues and mail logs. But as there are more
> than 350 messages being anonymized every day, you have to be pretty perverted
> to scan everything...
> 
> Another thing is mail failures. I've had cases of mail routers doing the wrong
> thing with % addresses, "shortcutting" the path to the destination site.
> This could cause your mail to go to the final destination without ever
> touching my server (and thus without getting anonymized). This can be avoided
> by using the X-Anon-To: method.
> 
> And if your return address bounces for some reason (nameservers down,
> temporary configuration failures etc.), the original sender and/or
> postmasters on the way might get error messages showing your true
> identity, and maybe even the full message.
> 
> And crackers are just too clever. Undoubtedly somebody is going to come
> up with some novel method....  Not much I can do about that...
> 
> If you intend to mail/post something that might cost you your job or
> marriage or inheritance, _please_ send a test message first. The software
> has been pretty well tested, but some mailers on the way (and out of my
> control) screw things up. And if you happen to find a problem, _please_ for
> the sake of all the other users, _let me know asap_.
> 
> And _please_ use the appropriate test newsgroups, such as alt.test or
> misc.test. Yes, _you_ might get excited by reading 2000 "This is a test.."
> messages on alt.sex, but I warn you that most psychologists consider this
> rather aberrant...
> 
> And remember this is a service that some people (in groups such as
> alt.sexual.abuse.recovery) _need_. Please don't do anything stupid that
> would force me to close down the service. As I am running my own company,
> there is very little political pressure anyone can put on me, but if
> somebody starts using the system for criminal activities, the authorities
> might be able to order me to shut down the service. I don't particularly
> want to find out, however...
> 
> If you think these instructions are unclear and confusing, you are right. If
> you come up with suggestions for improving this text, please mail me! Remember
> English is my third language...
> 
> Safe postings!
> 
> 	Julf
> 
> - - - ------------------------------------------------------------------- - - -
> Johan Helsingius     Kuusikallionkuja 3 B 25   02210  Espoo  Finland     Yourp
> net: julf@penet.fi   bellophone: int. +358 0400 2605  fax: int. +358 013900166
> 


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 07:11:12 PST
To: honey@citi.umich.edu (peter honeyman)
Subject: Encrypting Remailer Logs
In-Reply-To: <9212221344.AA03085@toad.com>
Message-ID: <9212221510.AA26463@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> that the best way to secure the remailer logs is to encrypt them.
> 
> which raises a sticky point, since i don't see an easy way to do that
[...] 
> see is to enter a password at boot time (or when the remailer is started).

There is an easier way.  Just generate a public/private key pair.  Store
the public key on the machine, and have the remailer encrypt its logs
with the public key.  Someone seizing the machine could not find anything,
since they do not have the private key.

Store the private key on another machine, or on a floppy.  When there's
a problem, you can transfer the encrypted log to the machine with the
private key, and then you can decrypt the log to see what went wrong.

Generate a new key pair weekly, and destroy the old private key.  You
should never need logs older than a week for troubleshooting.

p.s.

> > Unix weenies of old will recall "clri" to clear an inode. ...
> 
> > -- so why not just write a little C program ...
> 
> u.w.o.o. often go to great lengths to avoid writing a few lines of c,

So how about a few lines of perl?  

 
--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: peter honeyman <honey@citi.umich.edu>
Date: Tue, 22 Dec 92 08:21:43 PST
To: cypherpunks@toad.com
Subject: Cryptology Column -- New and Coming Books
Message-ID: <9212221621.AA05549@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Excerpted and reprinted with the author's permission
from SIGACT NEWS, Volume 23, Number 4

Cryptology Column -- New and Coming Books

Gilles Brassard
brassard@iro.umontreal.CA 

Departement d'informatique et de R.O.  
Universite de Montreal 
C.P. 6128, Succ. ``A'' 
Canada H3C 3J7

31 October 1992

Research supported in part by the
E.W.R. Steacie Memorial Fellowship
(Canada's Nserc).

1  Introduction

An outstanding book on cryptology has hit the market this year.
Although the news may be stale to many of my readers, Gustavus J.
Simmons has edited a 640-page mammoth of a masterpiece titled
Contemporary Cryptology: The Science of Information Integrity,
published by IEEE Press.  In addition, other new and exciting books
are expected to come out soon.

2  Simmons' Book

Simmons' Contemporary Cryptology grew out of a special issue of the
Proceedings of the IEEE, which he edited in May 1988.  I remember how
proud -- and rightly so! -- Simmons was concerning that issue: his
favourite line was that ``this is an example where the whole is better
than the sum of its parts''.  As a consequence of the excellent
reception of his special issue, he was commissioned by the IEEE to edit
the book we are now discussing.  Speaking of excellent reception, the
first printing of Simmons' book was sold out in months.  The second
printing, which I have not seen yet, corrected all mistakes that had
been found in the first.  In addition, reference citations for
publications that had appeared after the first printing went to press
were completed, and a number of footnotes, notes added in proof and
inserted paragraphs to update significant statements of fact that had
occurred in the interim were made.

It is amusing to note that the book's cover is very similar to that of
the Proceedings, except that Simmons corrected an embarrassing mistake
that I pointed out to him on the Proceedings cover (see if you can spot
it!).  The book is hard cover, pleasant to manipulate, and handsome.
Unfortunately, I found the binding of my own copy to be slightly
defective, but I was told that this problem was corrected with the
second printing.

Contemporary Cryptology is a collection of chapters, many of which
written by top researchers in the field, which together span most of
the exciting developments that have changed cryptology forever in the
past twenty years.  Simmons himself contributed the foreword and three
chapters.  His master plan -- the table of contents -- is well
conceived as few important topics have been left out.  (Nothing is
perfect, though ... the book is lacking a chapter on quantum
cryptography!) Unfortunately, even a good coach cannot enforce perfect
coordination concerning who says what in a multi-author work.  This
book is no exception: it suffers from many repetitions of the same
concepts across chapters.

The main sections of the book are Cryptography, Authentication,
Protocols, Cryptanalysis, and Applications.  This is preceded by two
essays on the theme ``Contemporary Cryptology'': a foreword by Simmons
and an introduction by James L. Massey.  Massey's introduction to
cryptology is among the clearest and most useful I have ever seen that
can fit on as few as 36 pages (although another particularly noteworthy
concise introduction is Simmons' own entry in the Encyclopaedia
Britannica).  Massey's introduction covers some history, motivations,
all the basic notation, secret key cryptography (both in theory and in
practice, including a review of Shannon's information theory, the DES,
stream ciphers and Ueli Maurer's recent bid to get around Shannon's
discouraging theorem that the one-time-pad is the most economical
system that can provide perfect secrecy), authentication (a section
that I found particularly useful last time I taught on the subject),
public key cryptography (including one-way functions, public key
distribution, RSA and variations on the theme), and protocols.  Massey
even includes an enlightening discussion of secret versus open research
in cryptology.  One thing I learned from Massey's introduction is that
the notion of one-wayness goes back to at least 1873!  On the negative
side, nothing is said about probabilistic encryption and zero-knowledge
protocols, and digital signatures are not covered adequately.  But
then, Massey makes an explicit point that it was not his purpose to
survey research in cryptology.  Moreover, these topics are treated in
other chapters of Simmons' book.

After the foreword and introduction, the first section deals with
cryptography.  The topics covered are ``The DES: Past and Future'' by
Miles E.  Smid and Dennis K. Branstad, ``Stream Ciphers'' by Rainer A.
Rueppel, ``The First Ten Years of Public Key Cryptography'' by
Whitfield Diffie, ``Public Key Cryptography'' by James Nechvatal, and
``A Comparison of Practical Public Key Cryptosystems Based on Integer
Factorization and Discrete Logarithms'' by Paul C. van Oorschot.  The
chapter on DES goes from the birth of the system to predictions
concerning the coming decade, not forgetting to cover the controversy
surrounding it and its many applications.  New, post-DES algorithms are
also discussed.  However, the coverage of attacks against DES is far
from complete; in particular, differential cryptanalysis is not even
mentioned.

Rueppel is a leading expert in stream ciphers, and the author of a
well-known book on the topic; he was therefore the natural choice of
author for Simmon's second chapter.  After introducing all the relevant
background, Rueppel covers information-theoretic, system-theoretic and
complexity-theoretic approaches to stream ciphers.  A large number of
pseudo-random generators are described.  The chapter also considers
randomized stream ciphers, which can provide practical provable
security in the presence of a large,  publicly accessible, body of
randomness.

Diffie's chapter on the history of public key cryptography is a pure
gem, which could only have been told so well by the horse's mouth.  In
my opinion, Simmons' book would be worth buying even if only for those
39 pages.  Of particular interest is the story of how Ralph Merkle,
then at Berkeley, invented as early as 1974 the concept of public key
distribution, and how unsuccessful he was in explaining and publishing
his idea.  (Merkle told me that Bob Fabry, contrary to many others, had
understood the idea and had encouraged him to seek fame and fortune
with it!) Diffie goes on explaining the principles of public key
cryptography and the early solutions, including RSA.  An interesting
section on key management, the main aspect that was sorely missing from
the early papers on public-key cryptography, is provided.  Diffie's
chapter continues with applications, such as the secure phone system,
and implementations.  Finally, Diffie goes beyond what his title
promised, as he tackles new directions for public key cryptography.

The next chapter, by Nechvatal, is by far the longest in this book (120
pages).  It was written as a stand alone piece, which is unfortunate in
this context as it presents significant overlap with other chapters of
the book.  In my opinion, the author would have been better advised to
transform his writing into a monograph of its own.  Nevertheless, this
chapter is well written and contains a wealth of valuable information.

In the last chapter of the first section, van Oorschot reviews the
currently best algorithms for extracting discrete logarithms (both in
GF(2^n) and in elliptic curves) and for factoring, including a detailed
analysis of their efficiency.  This is used as the basis of a
comparison between El Gamal's cryptosystem and RSA.  Elliptic curve
cryptosystems are also considered.

Section 2 deals with authentication.  It is composed of one chapter on
``Digital Signatures'' by Chris J. Mitchell, Fred Piper and Peter Wild,
and ``A Survey of Information Authentication'' by Simmons.  The chapter
on digital signatures provides thorough coverage of the theory,
practice and applications of signatures, including a section on
hashing.  Nonetheless, it is sad that David Chaum's elegant notion of
Undeniable Signature did not find its way in that chapter even though
it was published as early as 1989.  The next chapter was written by the
man I consider to be no less than ``the Shannon of authentication'',
the book's editor himself.  Indeed, Simmons developed in the 1980's a
theory of authentication that parallels that of Shannon for privacy.
This chapter shows a good balance between theory and practice, which
could also be said about its author.  I must admit, however, that I
found Massey's exposition of Simmons' theories in the Introduction
easier to follow than Simmons' own.  Nevertheless, I read this chapter
with particular interest and enjoyment.

The next section deals with protocols.  It consists of an ``Overview of
Interactive Proof Systems and Zero-Knowledge'' by Joan Feigenbaum and
``An introduction to Shared Secret and/or Shared Control Schemes and
Their Applications'' again by Simmons.  It must be pointed out that the
very important (in my opinion) topic of multi-party computation, also
known as ``post-cold war cryptography'', is missing altogether from
this section on protocols and indeed from the entire book as far as I
can tell.  I like Feigenbaum's succinct exposition of interactive
proofs and zero-knowledge, even though it was written more from a
computational complexity point of view than from a cryptographic point
of view.  For instance, the existence of an interactive proof system
for the permanent is of considerable interest in complexity theory, as
it lead the way to Shamir's proof that IP = PSPACE (see my column in
Vol. 21, no. 1, 1990) but I fail to see its direct cryptographic
significance.

Turning now to the chapter on secret sharing, I can think of no one
better suited than Simmons for writing it.  After reviewing Shamir's
and Blakley's (very different) original ideas, he addresses access
structures more general than simple threshold schemes.  Most of the
schemes explained are based upon geometric considerations.  An
application to key distribution is provided.  A comprehensive
bibliography follows.

The fourth section deals with cryptography's sister discipline:
cryptanalysis.  It consists of one chapter on ``Cryptanalysis:  A
Survey of Recent Results'' by Ernest F. Brickell and Andrew M. Odlyzko,
and one chapter on ``Protocol Failures in Cryptosystems'' by Judy H.
Moore.  The chapter on cryptanalysis surveys recent cryptanalytic
achievements.  Particularly thorough treatment is given to the breaking
of the knapsack and of linear congruential generators.  Other
cryptosystems and signature schemes are covered.  Information is also
provided on the state-of-the-art concerning the cryptanalysis of yet
unbroken systems such as RSA, discrete exponentiation schemes, the
McEliece cryptosystem, and the DES.  Recent developments such as the
number field sieve for factoring and the differential cryptanalysis
technique are mentioned, but Biham and Shamir's attack on the full
16-round DES was achieved only after Simmons' book went to press.

Moore's chapter on protocol failures addresses an interesting problem:
it tells you how to cheat an application centered around a cryptosystem
without in fact breaking the cryptosystem itself.  In other words, even
good cryptosystems are potentially vulnerable when improperly used, or
when used according to a badly designed protocol.  Guidelines are given
to avoid such traps.  (Perhaps the most spectacular protocol failure in
history concerned the Enigma during World War II, but this is of course
not treated in Moore's chapter!)

The book closes with a section on applications.  It contains one
chapter on ``The Smart Card:  A Standardized Security Device Dedicated
to Public Cryptology'' by Louis C. Guillou, Michel Ugon and
Jean-Jacques Quisquater, and a chapter on ``How to Insure That Data
Acquired to Verify Treaty Compliance Are Trustworthy'', once more by
Simmons.  The chapter on smart cards describes what a smart card is and
what it can do.  The important issue of standardization is treated at
length.  Significant information is given on the technology behind
smart cards.  Naturally, most of the chapter is concerned with security
issues and cryptographic applications, such as authentication.  The
book's final chapter deals with real life field work pioneered by the
editor at Sandia National Laboratories, which is the result of nearly
two decades of development.  I prefer to say no more so as to keep your
appetite whetted!

In conclusion, this is a remarkable book, which I very strongly
recommend as necessary addition to the library of any serious
researcher in the field of cryptology.

3  Other books

These are exciting times for cryptoreaders.  In addition to Simmon's,
other promising books are due to appear soon.  Even though I prefer to
wait until they have come out to review them in detail (despite the
fact that I have seen preliminary versions), I cannot resist the
temptation to give you an avant gout.

Eli Biham and Adi Shamir have written up in great detail their
differential cryptanalysis technique and how it applies to the full
16-round DES as well as to other cryptosystems and hashing functions.
This is along the lines of Volume 4, number 1 of the Journal of
Cryptology, only more of it and better.  The preliminary title of their
book is Differential Cryptanalysis of the Data Encryption Standard.  It
will be published by Springer-Verlag.

Starting from notes taken by the students of a class he taught at the
University of California, Berkeley, Mike Luby has written
Pseudorandomness and Applications, which will be published by Princeton
University Press.  The book, now complete in the opinion of its author,
is undergoing a review process.  In it, Luby places pseudorandomness at
the heart of cryptography.  He explains how to produce
cryptographically secure pseudorandomness and how to use it for various
cryptographic purposes.  As one of the researchers to whom we owe the
proof that one-way functions are necessary and sufficient to obtain
cryptographically strong pseudorandom generators, Luby was the logical
author to write this authoritative book.

In addition, allow me to indulge in mentioning that my own
Springer-Verlag monograph Modern Cryptology:  A Tutorial is expected to
come out in French this November.  It will be published by Masson under
the title of Cryptologie Contemporaine.  Contrary to the previous
translation into Italian (also published by Masson), the French version
(translated by Claude Goutier) was fully revised and updated by the
author.  For instance, the number of references went up from 250 to 366
(you better tackle them on a leap year if you cannot handle more than
one per day!).

Have you written something lately?  If you have, I would appreciate
hearing about it.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 22 Dec 92 09:03:06 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Remailers.
Message-ID: <921222165319_74076.1041_DHJ39-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

One problem with the current encrypted remailers that people should
be aware of is that, since they operate unattended, they have to be
able to decrypt messages automatically.

This means that when an incoming messages arrives, the remailing software
automatically runs PGP on the incoming message to do the decryption.
But to decrypt, PGP has to be given the pass phrase for the remailer's
secret key.  The only way this can be done is to have the pass phrase,
IN THE CLEAR, in the remailing software scripts.

The scripts are (or should be) protected using the Unix file system
so that only the owner and root can read them.  But it's important to
know that root has access both to the secret key ring which holds the
remailer's key, and to the pass phrase which will activate that key.
This means that, at any time, root can find out the secret key of the
remailer, and read all messages encrypted for that remailer.

I don't think there is any way around this problem if the remailer is
going to run unattended.  The only real solution is to operate on a
machine where it doesn't matter whether root knows the key; that is,
a machine where root is the operator of the mailing list.

Hal
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzcZ0agTA69YIUw3AQEFhAQAlloC1eyaIuJDG91VzPoRv0MjzKlob8Te
C3N7XWLvszypOgKNBoEb1z8fF5ZsS20NhhRhtr7A3J4jxe88vGuea0Kvxzj4NGd4
bQeewhYk01ygoLzZOwv8BnN6pE7/uxk5POWq3XQuX80VQzistePfRRdNozTA09EY
4bBOr3s9Ig8=
=nJ/a
-----END PGP SIGNATURE-----

My public key, signed by PRZ:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
=fF6Z
-----END PGP PUBLIC KEY BLOCK-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 22 Dec 92 09:02:47 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Remailer encryption.
Message-ID: <921222165347_74076.1041_DHJ39-2@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

From: miron@extropia.wimsey.com (Miron Cuperman)

> In any case, the current scheme for ARA's is insecure.  This is
> because people can send plaintext messages attached to the ARA.
> This allows breaking anonymity by monitoring of the traffic from
> all remailers and waiting until the message appears at one of
> the outputs.
> 
> I will implement a more secure scheme.  The ARA will include
> encryption instructions for each remailer.  Since each remailer
> will be doing a transformation on the message, the attack above
> will not be feasible.

I'd like to hear more about this plan.  What kind of encryption
instructions would be used in the ARA?  Would they be public key or
secret key?

Chaum's "Mix" paper in CACM (1981?  I don't have my refs handy) had
a concept where at each step the remailer would encrypt the outgoing
non-address part of the message with a DES key found in the anonymous
address.  The user would remember all the DES keys used in the ARA
and un-apply them in reverse order to reconstruct the original message.
This would require some special software, I'd think, to remember the
DES keys and unapply them (and to construct the anonymous address).
(Actually, Chaum didn't specify DES but rather just an unspecified secret
key system.  If PGP were used for some of this then perhaps IDEA would
be a good choice.)

This system sounded pretty complicated, and it still had the problem
that by sending multiple messages to the same address a remailer could
do some simple traffic analysis and break the ARA.  E.g. it would send
5 messages to an ARA today, and discovers that it later gets 5 messages
for user X (because it happens to be the last remailer in the ARA chain).
Tomorrow, it sends 10 messages to that same ARA, and discovers 10 messages
for that same user.  The next day it sends 7 messages to the ARA, and
discovers 7 messages for that user.  Eventually it can deduce that the
user and the ARA go together.

To avoid this, Chaum calls these "one-time" ARA's and recommends that
mixes not accept messages for the same ARA more than once.  I don't
think this is a practical suggestion, though, since a one-time ARA is
not useful enough.

Hal Finney
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzcdKKgTA69YIUw3AQFK9wP/a27AgcL4ppMpYIbDfBy6Vw8NTjJzKpsL
hQibQ3XO3wPFURS3Mn51eYLyYRuJPY1/Ve+Y1Kbb6oLiW1u8Btw8CxvB1xe05f32
j0JwzSN1yL8blGMh4JxxXZI0t3SViJ1COt6p+I1SYLjftte/0YX0gc6dweFNUnkZ
5VC4FH2WCbQ=
=+Jx9
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 10:59:24 PST
To: cypherpunks@toad.com
Subject: IEEE Ordering Info
Message-ID: <9212221858.AA07594@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


If you want to order the book Peter posted about, call 800 678 4333,
press 1, then ask for Contemporary Cryptology book by Simmons.  

It's $79.95 (+$6 s/h).  Probably less if you are a member of IEEE.

I am in no way associated with IEEE Press, I just ordered the
book, and wanted to make it simple for anyone else who wants to.

(I ftp'd an info file from ieee.org, got a non-800 phone number,
called, was transfered and put on hold for x number of times, until
someone was able to give me the above 800 number that can be used
to order their publications.  I didn't want everyone to have 
to do this).


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Tue, 22 Dec 92 19:40:22 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Remailers
Message-ID: <ywm8VB8w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


I'd like to thank Eric Hughes and Mike Sherwood (who wrote privately)
and Hal Finney (who responded here) to my requests for enhancements to
Eric's remailer code.
 
By the way, Hal, your signature did not match the associated
plaintext:
 
   WARNING: Bad signature, doesn't match file contents!
 
   Bad signature from user "Hal Finney <74076.1041@compuserve.com>".
   Signature made 1992/12/19 21:43 GMT
 
This is likely due to some trailing blanks in your plaintext. I've
written to Branko to try to get PGP to remove trailing blanks if
-t is active.
 
First, I'm glad Eric agrees that anonymous posting to newsgroups
is a good idea and is on his "to do" list. Until then, thanks to
Hal for posting the info about the ucbvax gateway. I had that info at
one time, before hearing about remailers, but discarded it since I
thought I'd never use it.
 
I'm sorry Eric doesn't agree that stripping the .sig is a good idea.
I respectfully dissent. I've found that I can probably disable
my own automatic .sig, so I suppose this isn't too urgent.
Nevertheless, I would think it desirable to make remailers as easy to
use as posible. Having to remember to disable the automatic .sig is
certainly an inconvenience.  Forgetting to do so could potentially
be very embarrassing or even incriminating!!
 
The pax remailer uses "--" or "__" as sig delimiters (according to
their docs) & apparently this is satisfactory.  I think this means
that "----" would NOT be a delimiter, so it would be unlikely to be
used by mistake.  I wouldn't mind a more explicit delimiter, for
example
 
::--Remailer cut HERE--
 
if Eric thinks "--" is too ambiguous or is likely to be used
inadvertantly in the middle of a msg.  Anyway I guess I can
muddle through for the time being.
 
I agree with Hal that the pax remailer can probably be the first
in a chain to Eric remailers.  Probably also the last in a chain
of Anonymous returns.  But I don't see how pax could be used in
the middle of a chain.  I would encourage Eric to correspond with
the guy running the pax remailer:
 
   anon.admin@pax.tpa.com.au (a human)
 
to see if you couldn't come up with a common remailer code with best
features of both.  Certainly it would be great to have an Eric-style
remailer running in Australia!!

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Tue, 22 Dec 92 18:00:24 PST
To: cypherpunks@toad.com
Subject: Amtrak San Jose - San Diego for Usenix
Message-ID: <9212230159.AA19415@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


Costs $107 round trip, and takes about 14 hours each way.

FYI.

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: D Anton Sherwood <dasher@well.sf.ca.us>
Date: Tue, 22 Dec 92 20:00:22 PST
To: cypherpunks@toad.com
Subject: Re: Remailer Policies
Message-ID: <199212230354.AA20595@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


Keith Henson asked:
> Re logs and trying to destroy them when the cops are beating down your
> door, wouldn't it be a lot better to keep them encrypted?  Keith
 
Here's a lame question from a beginner who hasn't even downloaded PGP:
 
Am I supposed to memorize my private key, lest cops beat down the door while
I'm out?
 
Anton Sherwood                                          dasher@well.sf.ca.us
+1 415 267 0685                 1800 Market St #207, San Francisco 94102 USA




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Tue, 22 Dec 92 20:07:09 PST
To: cypherpunks@toad.com
Subject: Signing ascii text
Message-ID: <9212230406.AA28094@servo>
MIME-Version: 1.0
Content-Type: text/plain


I see some potential problems here as people start signing ASCII text
(e.g., email messages, etc). Is there a convention for the end of line
sequence that is to be used for the copy of the file that is run through
the hash function? If there isn't, then the file hash will depend on the
local end-of-line convention, which is bad.

I'm facing this problem right now in an experimental "XMD5" command that
I've added to my FTP server. The idea is to let you compute a hash on
a remote file so you can compare it with a local file without actually
having to send it. It works great in binary mode, but ascii mode is
problematic.

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: karn@qualcomm.com (Phil Karn)
Date: Tue, 22 Dec 92 21:10:41 PST
To: yanek@novavax.nova.edu
Subject: Re: Signing ascii text
Message-ID: <9212230509.AA28220@servo>
MIME-Version: 1.0
Content-Type: text/plain


Okay, the cr/lf convention is what I suspected was the case. That's what
I'll implement. Can't do much about the munged messages...

Phil




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 20:32:03 PST
To: karn@qualcomm.com (Phil Karn)
Subject: Re: Signing ascii text
In-Reply-To: <9212230406.AA28094@servo>
Message-ID: <9212230431.AA25182@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> (e.g., email messages, etc). Is there a convention for the end of line
> sequence that is to be used for the copy of the file that is run through
> the hash function? If there isn't, then the file hash will depend on the

Canonical Text has a CR and LF at the end of each line.  This is 
documented in some RFC.  All (most?) protocols used on internet such
as smtp, finger, etc, use this format.  The possible justification
is that an extra linefeed or a carriage return is not as bad as a missing
one.  

For e-mail you may have other problems, if the messages go through
gateways that like to munge messages.  For example your tabs could
be expanded into spaces, or the other way around.  Some character
set conversions may be done.

Blank lines may be removed or added.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 22 Dec 92 21:53:28 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Signing text messages...
Message-ID: <921223054929_74076.1041_DHJ39-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


My public key, for those wanting to check the sig on the message below:

-----BEGIN PGP PUBLIC KEY BLOCK-----
mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
=fF6Z
-----END PGP PUBLIC KEY BLOCK-----

-----BEGIN PGP SIGNED MESSAGE-----

Phil Karn asks about end-of-line conventions for signed text messages.
PGP uses the convention of lines terminated by carriage-return-line-feed.
On Unix systems or other systems which don't use that convention,
it attempts to change the message into this "canonical" text mode
before calculating or checking the signature.

The issue of trailing blanks is more problematical.  Some mail gateways
and some mail "user agent" software apparently take liberties with
blanks at the end of lines.  The PGP canonical text format does not
include any specification for whether lines could or could not have
blanks at the end.  If mailers will leave trailing blanks alone, then
PGP cleartext signed messages will have correct signatures.  If some
intervening mailer has added or removed trailing blanks, then the
signatures will be wrong.  Presumably something like this has happened
to my signed message on which Edgar found a bad signature.  Perhaps
Edgar could try stripping any trailing blanks from his copy of my
message and see if it then signature-checks OK.  I'll double-check
that this message is signed with no trailing blanks.  Then if you get
a bad signature, I predict that you must have trailing blanks in your
copy of the file.  I'd appreciate hearing whether this prediction is
correct.

It would be possible to change PGP's canonical text format
to specify that lines have no blanks at the end.  In that case, PGP
would, whenever it computed or checked a signature on a text file,
process the file to make sure that each line ended with a CRLF preceded
by no trailing blanks.  I think this would solve a lot of the gateway
problems.  But it would be a somewhat more "aggressive" change to what
the user is asking PGP to sign.

The design of PGP's cleartext signature was influenced by PEM, which
also uses a canonical text format for line terminators, but doesn't
deal with trailing spaces, as far as I know.

The real solution, IMO, is to fix those broken mailers that add
or remove spaces.  I don't see why this behavior has ever been put
into mail gateways.

Hal Finney
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzfNHqgTA69YIUw3AQGNdwP/Q51Lvmee1cTb865aInePsRxMTe4qfjeU
DSP8o5hHlBKbII8mCrU/WHZ7upjO3ak4E6wZDyOexsfJFH4FIMnDueihrVVXevlA
FWUQopZIyG4P5Wzofgra8BSjw5WzVZncW2alPQFuB40D9N9VgyopX8IktktVPs4p
qDkHsn9zIpU=
=K/Ui
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 22 Dec 92 21:55:46 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Pax and .fi remailers
Message-ID: <921223054957_74076.1041_DHJ39-2@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


Upon more thought, I don't see a really good way to use the PAX
remailer in conjunction with our remailers based on the scripts of
Eric Hughes.  The PAX remailer can only be used to send messages to
those who have "registered" with the remailer to receive an anonymous
ID there.  So, for PAX to work with our remailers we would have to
register.  For example, my remailer at hal@alumni.caltech.edu would
have to register with PAX and receive an anonymous ID, like
"anon.100@pax.tpa.com.au".

Then, to use a two-hop remailer consisting of first PAX and then mine,
you would prepare a message as usual for my remailer:

====================
::
Request-Remailing-To: dest

This is a message for two-hop anonymous remailing.
====================

Perhaps you would encrypt this using my remailer's public key, getting:

====================
::
Encrypted: PGP

-----BEGIN PGP MESSAGE-----
Version: 2.1

hEwCG6rHcT8LtDcBAfwLWYgWXpCoi7TjoeVttBYpk3KPbiYf9L9CCegfYlvj56RA
OFrijYag+jqNlHQXmO52bXL8PaNUowD7a2pFY80WpgAAAGt/RXNzaWkI/b3CkviB
eh/piaUDxgfPd4npcURHtUCEeh8bPpzVaI9qm6xZlxSaJif+CtFqyuaRezj+hcXR
YT9JOl93LAxQJITeYUlPXgkBEvyB4u3HjpCDSS5NETDcqd8rtBspzUvlcmqT1g==
=d356
-----END PGP MESSAGE-----
====================

You would then send this to anon.100@pax.tpa.com.au.  (NOTE: Don't
try this - I haven't yet gotten an anonymous ID at PAX.)  PAX
would forward it to my remailer, unchanged, which would then decrypt
it and send it onward.  Oh, yes, PAX would also strip the .sig,
which is perhaps why you'd want to do this.

But for this to work, I have to publically announce that my remailer,
hal@alumni.caltech.edu, can be reached at PAX "anonymous" address
anon.100@pax.tpa.com.au.  This seems a little strange, as the PAX
address is then no longer anonymous.  I have to tell everybody what
the address is in order for it to be useful.

So, the PAX remailer doesn't really add much anonymity, but it does
excise your .sig.  It's not clear that it's worth it just for that.

On a more positive note, the other remailer, in Finland, is much more
promising for our purposes.  It has a remailing capability similar
to ours.  You could send mail to: hal%alumni.caltech.edu@anon.penet.fi,
and it would forward the mail to hal@alumni.caltech.edu.  This is
similar functionality to a non-encrypting form of the remailers we
are operating, and so it can help confuse things.

Also, this remailer could be used in a chain of our remailers by
using an address of the proper form.  For example, mail sent to
the Rebma remailer, then to Finland, then to the Rosebud remailer, could be
done by putting, at the front of your message:

::
Request-Remailing-To: elee7h5%rosebud.ee.uh.edu@anon.penet.fi

::
Request-Remailing-To: <dest>

Then a blank line, then your message itself.  Mail it to remailer@rebma.mn.org.
I haven't tried this but it should work, theoretically.

Hal
74076.1041@compuserve.com


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 22:35:05 PST
To: ddfr@aol.com
Subject: Encryption Technology
Message-ID: <9212230634.AA27849@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain



> I am going to be teaching a seminar on computer law next quarter. One area
> the casebooks seem to entirely ignore is encryption--the area where
> technology is currently supporting privacy and weakening state power. I would
> appreciate either references to or on line copies of useful material. The
> three main things I need are a clear explanation of the technology (public
> key cryptography in particular),

I assume that you just want an explanation of what the technology does, not
how exactly it works, i.e. I am not going to include the formulas and
algorithms, just a description of what it does and how it can be used.

Here's a summary of a couple of the most relevant technologies:

PUBLIC KEY CRYPTOGRAPHY -- each person generates two keys, one is called
teh public key the other is private.  These two are related in that what is
encrypted with one can only be decrypted with the other.  It is impossible
(computationally infeasible) to derive one knowing the other.  The most
popular public key cryptography algorithm is RSA, which is based on the
ease of multiplying large primes, and the difficulty of factoring the
product.

How it is used: you publish the public key, while keeping the private key
to yourself.  Anyone can send a secret message to you by encrypting it with
your public key.  You are the only one that can decrypt the message, since
only you have the private key.

You can reply by encrypting your message with their public key, and they
can decrypt it with their private key.


DIGITAL SIGNATURES -- techniques that are used to verify that a message
claiming to be from you was actually written by you.  To do that, you
compute a "message digest", which is similar to a "checksum" in that it can
be used to check that the message has not been altered.  Then you encrypt
the "digest" with your private key and attach to the message.  Currently
the most popular "digest" algorithm is MD5.

To verify a signature:  the person verifying computes the same checksum,
then decrypts the checksum attached to the message.  If the two match, the
message must have been signed by you, since no-one else has your private
key, and could not have generated the signature.


DIFFEY-HELLMANN KEY EXCHANGE --  a protocol by which two communicating
parties can arrive at a secret piece of information that can not be known
to a passive eavesdropper (as in a wiretap), and can not be recovered from
analysis of recorded communication.  This secret piece of information is
usually used as the key for a conventional cryptography algorithm such as
DES or IDEA to encrypt following communication.  


SENDER UNTRACEABILITY -- use of a protocol by which one of a group of
commnicating entities can send a public message, while it is impossible
to trace the message to the sender.  This can be used to send messages
anonymously or pseudonymously and untraceably.  One of the protocols that
makes this possible is David Chaum's dc-net protocol, in which every
participant sends some data, and when all the data are combined, the
anonymous message emerges.  Another is the mix-net, or "remailer" approach.
In this case, you send your message to a re-mailer, with encrypted
instructions on where to send it.  By sending your message through a chain
of such remailers, untraceability is achieved.


RECEIVER UNTRACEABILITY -- a method by which you can retrieve a message
sent to you, without anyone having any way of knowing that you received the
message, or indeed if you received any message at all.  

How it works:  anyone wanting to leave a message to you encrypts it with
your public key, and posts it on a "bulletin board".  You download all the
messages from the bulletin board periodically, and see if you can decrypt
any using your private key.  



DIGITAL CASH -- one entity creates some amount of digital "tokens", which
may then be transfered to other people, who can transfer them between each
other, and when they are returned to their creator, he can not trace the
transactions that have occured, only the total balance of a person at the
end of the set of transactions.


> a clear explanation of how it can be used and why it matters,

Each of these technologies by itself can not accomplish much.  But if all
these are put together, any person can send messages to any other person,
without anyone but the two of them knowing that a message was sent, or what
it said.

As for why it matters, I include here Timothy C. May's Crypto Anarchist
Manifesto:


The Crypto Anarchist Manifesto

Timothy  C.  May
tcmay@netcom.com


A specter is haunting the modern world, the specter of crypto 
anarchy. 

Computer technology is on the verge of providing the ability for 
individuals and groups to communicate and interact with each other 
in a totally anonymous manner. Two persons may exchange 
messages, conduct business, and negotiate electronic contracts 
without ever knowing the True Name, or legal identity, of the other. 
Interactions over networks will be untraceable, via extensive re-
routing of encrypted packets and tamper-proof boxes which 
implement cryptographic protocols with nearly perfect assurance 
against any tampering. Reputations will be of central importance, far 
more important in dealings than even the credit ratings of today. 
These developments will alter completely the nature of government 
regulation, the ability to tax and control economic interactions, the 
ability to keep information secret, and will even alter the nature of 
trust and reputation.

The technology for this revolution--and it surely will be both a social 
and economic revolution--has existed in theory for the past decade. 
The methods are based upon public-key encryption, zero-knowledge 
interactive proof systems, and various software protocols for 
interaction, authentication, and verification. The focus has until now 
been on academic conferences in Europe and the U.S., conferences 
monitored closely by the National Security Agency. But only recently 
have computer networks and  personal computers attained sufficient 
speed to make the ideas practically realizable. And the next ten 
years will bring enough additional speed to make the ideas 
economically feasible and essentially unstoppable. High-speed 
networks, ISDN, tamper-proof boxes, smart cards, satellites,  Ku-band 
transmitters, multi-MIPS personal computers, and encryption chips 
now under development will be some of the enabling technologies. 

The State will of course try to slow or halt the spread of this 
technology, citing national security concerns, use of the technology 
by drug dealers and tax evaders, and fears of societal disintegration. 
Many of these concerns will be valid; crypto anarchy will allow 
national secrets to be trade freely and will allow illicit and stolen 
materials to be traded. An anonymous computerized market will 
even make possible abhorrent markets for assassinations and 
extortion. Various criminal and foreign elements will be active users 
of CryptoNet. But this will not halt the spread of crypto anarchy.

Just as the technology of printing altered and reduced the power of 
medieval guilds and the social power structure, so too will 
cryptologic methods fundamentally alter the nature of corporations 
and of government interference in economic transactions. Combined 
with emerging information markets, crypto anarchy will create a 
liquid market for any and all material which can be put into words 
and pictures. And just as a seemingly minor invention like barbed 
wire made possible the fencing-off of vast ranches and farms, thus 
altering forever the concepts of land and property rights in the 
frontier West, so too will the seemingly minor discovery out of an 
arcane branch of mathematics come to be the wire clippers which 
dismantle the barbed wire around intellectual property.

Arise, you have nothing to lose but your barbed wire fences!


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.


> and a brief summary of the present legal/political
> situation--in particular, attempts and suggestions that have been made to
> control the technology.

The FBI has proposed a "Digital Telephony" bill, which would require all
providers of any kind of communications service to build in a wiretap
capability for the government.  Department of State is restricting the
export of any crypto software, claiming that it is a weapon, and therefore
falls under ITAR (International Traffic in Arms Regulations) rules.  Public
Key Partners (PKP) holds the control of patents that cover RSA, and
possibly the very idea of public key cryptography.  Someone (I can't
provide a reference) has proposed that anyone that uses encryption should
be required to register their key with the Justice Department, so that the
text could be decrypted if a search warrant is issued.  These are all the
attempts to control this technology that come to my mind right now.

The Electronic Frontier Foundation (EFF) can probably provide more
information (e-mail to eff@eff.org).
 
> David Friedman
> DDFr@Midway.UChicago.Edu
> DDFr@AOL.Com



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 22 Dec 92 22:56:29 PST
To: 74076.1041@CompuServe.COM (Hal)
Subject: Re: Pax and .fi remailers
In-Reply-To: <921223054957_74076.1041_DHJ39-2@CompuServe.COM>
Message-ID: <9212230655.AA28469@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> But for this to work, I have to publically announce that my remailer,
> hal@alumni.caltech.edu, can be reached at PAX "anonymous" address
> anon.100@pax.tpa.com.au.  This seems a little strange, as the PAX
> address is then no longer anonymous.  I have to tell everybody what

You don't have to tell anyone that your remailer is behind the anon.100
address.  You could just (anonymously, of course) announce that a
remailer is running, and can be reached by sending message to the
anon.100 address.  This way, no-one but the admins at pax can know
where the remailer itself lives.  This could be useful in case 
remailers are banned.


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: John W Noerenberg <jwn2@qualcomm.com>
Date: Wed, 23 Dec 92 09:08:22 PST
To: yanek@novavax.nova.edu (Yanek Martinson)
Subject: Re: Signing ascii text
Message-ID: <9212231707.AA03963@harvey>
MIME-Version: 1.0
Content-Type: text/plain


At 11:31 PM 12/22/92 -0400, Yanek Martinson wrote:
>> (e.g., email messages, etc). Is there a convention for the end of line
>> sequence that is to be used for the copy of the file that is run through
>> the hash function? If there isn't, then the file hash will depend on the
>
>Canonical Text has a CR and LF at the end of each line.  This is 
>documented in some RFC.  All (most?) protocols used on internet such
>as smtp, finger, etc, use this format.  The possible justification
>is that an extra linefeed or a carriage return is not as bad as a missing
>one.  

Which RFC are you referring to?  While it is true that 821, 822 (and other
RFC's which are concerned with email messages) define the end of line as a
CRLF, I'm not aware of an RFC which defines canonical text.  The style of
late has been to define a line "as described in rfc822" or some such.  But
I don't recall any rfc which defines canonical text spanning session-layer
(or higher) protocols.  Is there one?

john noerenberg
jwn2@qualcomm.com
noerenberg.j (Applelink)
===========================================================
Do not uselessly lament your luck that is giving way, your work that has
failed, your life's plans that have all ended in despair.  Like a man long
prepared, like a man of courage, bid her farewell, the Alexandria that
leaves you.
-- "The God Abandons Anthony", Constantine Peter Cavafy [1911]
===========================================================





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Messick <eric@parallax.com>
Date: Wed, 23 Dec 92 11:57:58 PST
To: cypherpunks@toad.com
Subject: Re: Signing ascii text
Message-ID: <9212231902.AA25740@parallax.com>
MIME-Version: 1.0
Content-Type: text/plain



I would like to argue for a weaker ascii text signature function in
PGP in addition to the current one.  It would canonicalize a file by
turning all sequences of white space into a single space and trimming
leading and trailing whitespace from the file before computing the
hash.  This clearly involves some major changes to the file, allowing
many files to hash to the same value, but a human would presumably
consider all of those files to have the same information content.  The
only case that I can think of where the information content of the
message could be changed with the signature remaining valid is if
information was contained in the pattern of whitespace in the file.
This should make the signature robust to most of the changes that a
mailer could make.  I would not advocate extending this to any
non-whitespace characters.

-- eric messick
eric@toad.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Doctor Zaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Wed, 23 Dec 92 11:30:19 PST
To: CypherPunks@Toad.Com
Subject: RE: Signing text messages...
Message-ID: <40694.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


In Message 23 Dec 92 00:49:30 EST,
  Hal <CompuServe.COM!74076.1041@netcomsv.netcom.com> writes:

>My public key, for those wanting to check the sig on the message below:

By including your public key WITH your signed messages, aren't you inviting
people to intercept it, replace it with they're own public key, and re-sign
the message?  If I didn't have a trusted copy of your public key already I
wouldn't be able to verify your signature.
TTFN!
DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Hal <74076.1041@CompuServe.COM>
Date: Wed, 23 Dec 92 08:42:59 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Re: Pax and .fi remailer
Message-ID: <921223163446_74076.1041_DHJ35-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Yanek points out a purpose for a PAX-hidden remailer:

> You don't have to tell anyone that your remailer is behind the anon.100
> address.  You could just (anonymously, of course) announce that a
> remailer is running, and can be reached by sending message to the
> anon.100 address.  This way, no-one but the admins at pax can know
> where the remailer itself lives.  This could be useful in case 
> remailers are banned.

The problem with this, it seems to me, is that the address of this
"secret" remailer is compromised whenever it sends something out.
I could just send a "Request-Remailing-To: <me>" message to this PAX
anon.100 address, and then look at the return address when the message
comes to me from this remailer.  So again the anonymity provided by
PAX seems to be lost.

Now, one way to avoid this would be for the secret remailer not to send
its outgoing mail directly to the requested destination, but rather
always to insert one or other remailers into the chain.  I think it was
Yanek himself (or Dr. Z?) who suggested this earlier.  This might work,
but as was pointed out, if everyone does this we'll just get into infinite
mail loops.

Still, it might be OK if a well-known public remailer were chosen,
especially one that was likely to be relativelly immune to pressure.
I noted in the discussion of the anon.penet.fi remailer the author made
the point that it was running on a machine in his house, one that he
owned and used in his independent business.  So presumably his machine
is not going to be easy to shut down.

(My remailer, OTOH, is running as part of what is basically a guest account
on a machine which is to be used just for email and a little telnet/ftp
activity.  I figure that the remailer performs an email function, speaking
broadly, so it's OK under the agreement I signed.  But I'm sure that if
the admin received some complaints I'd be kicked off.  So I can't make
any guarantees about how long it will be around.)

(This would be another piece of information that would be useful in the
remailer database being constructed by Eric Hollander - some comments
on how immune the remailer operator would be to political pressure due to
unpopular or illegal messages.)

If this well-known machine guaranteed NOT to do this remail-via-a-remailer
outgoing step, then it could be used by less politically secure remailers
to protect themselves from pressure.  In such a system, Yanek is right
that a remailer could run completely anonymously.

Perhaps someone would like to start up a remailer which runs under such
a system.

Hal Finney
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzhqjKgTA69YIUw3AQFNmAQAgioJMosbMCoit2XflfzK/wgIOkG8qBfG
JO3iTWRskVP5Gp43N1bs7W6YhgEXKWdJ/dqNoWrYV2/181zFhXh0xe7lsGifut1b
UQGW6DipYIMlW0TbNjhpiIWwAQChn/3NvTJtcBGL0GY3l4ZjMZFs2qBonc/Y1Boe
jWfWgQbHSXw=
=6y5/
-----END PGP SIGNATURE-----


Distribution:
  CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Wed, 23 Dec 92 13:46:51 PST
To: cypherpunks@toad.com
Subject: Re: Signing text messages...
Message-ID: <9212232118.AA23889@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


Dr. Zaphod writes:

> By including your public key WITH your signed messages, aren't you inviting
> people to intercept it, replace it with they're own public key, and re-sign
> the message?  If I didn't have a trusted copy of your public key already I
> wouldn't be able to verify your signature.

I'm not sure what attack you are proposing here.  Are you suggesting
that someone else could take credit for my (brilliant?) message by
removing the PGP signature and substituting one of their own?  But
digital signatures can't stop other people from doing this.

Or are you suggesting that someone else could create a bogus public
key claiming to mine, re-sign the message using that public key, and
then get people to think it was from me?  Or, worse, they could create
a whole new message saying "I am a turkey, signed Hal Finney", sign it
with this bogus "Hal Finney" public key, and post it.  Then I'd really
have egg on my face, right?

But no, I wouldn't, because people would (or should) know not to trust
a random public key to be from whom it claims.  My posted key is
signed by Phil Zimmermann.  This doesn't absolutely prove it is from
me, but I think it makes it worthwhile to post the key.

Anyway, the real reason I posted the key in this case was so that
people could check the cleartext signature to see if it had been
mangled by various mail gateways.  That was the topic of discussion in
the message, so I wanted to make it easy for people to try checking
the signature.

Hal
74076.1041@compuserve.com





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Messick <eric@parallax.com>
Date: Wed, 23 Dec 92 19:01:52 PST
To: cypherpunks@toad.com
Subject: Re: Signing ascii text
Message-ID: <9212232303.AA26569@parallax.com>
MIME-Version: 1.0
Content-Type: text/plain



I wrote:

>It would canonicalize a file by
>turning all sequences of white space into a single space and trimming
>leading and trailing whitespace from the file before computing the
>hash.

mark@coombs.anu.edu.au resopnded:

> If the message contained a table of figures formatted and seperated with
> spaces then that method would destroy the readability of the table.

The important part here is that the collapsing of whitespace would
only affect the message digest, not the text as seen by the user.  Two
texts which read the same, but differ in whitespace, would have the
same signature.  If you recieved both files, you could see the
difference in spacing, yet the same signature would be valid for both
files.  The main vulnerability is that a message whose meaning is
partially encoded it its whitespace (like an ascii graphic, map, or
chart) could have its meaning altered, without affecting the validity
of the signature.  Clearly one would not want to use this signature
method on such texts.  It would be a good feature for the signature
algorithm to warn the user if it detects a pattern of whitespace that
might convey information.  I am not sure how to detect this reliably,
though.

-- eric messick
eric@toad.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: "Doctor Zaphod" <ncselxsi!drzaphod@ncselxsi.netcom.com>
Date: Wed, 23 Dec 92 16:16:27 PST
To: CypherPunks@Toad.Com
Subject: Re: Signing text messages...
Message-ID: <57860.drzaphod@ncselxsi>
MIME-Version: 1.0
Content-Type: text/plain


In Message Wed, 23 Dec 92 13:18:54 PST,
  uunet.uu.net!ghsvax!hal@netcomsv.netcom.com (Hal Finney) writes:

>Or are you suggesting that someone else could create a bogus public
>key claiming to mine, re-sign the message using that public key, and
>then get people to think it was from me?

     Perhaps they could alter the message, use a bogus public key, and
     re-sign the message.

>But no, I wouldn't, because people would (or should) know not to trust
>a random public key to be from whom it claims.  My posted key is
>signed by Phil Zimmermann.  This doesn't absolutely prove it is from
>me, but I think it makes it worthwhile to post the key.

     I didn't realize you had included a signed key.  Minus one point
     for research.  Yes, people SHOULD know not to use a publicly posted
     key.  But do they?

>Anyway, the real reason I posted the key in this case was so that
>people could check the cleartext signature to see if it had been
>mangled by various mail gateways.  That was the topic of discussion in
>the message, so I wanted to make it easy for people to try checking
>the signature.

     Then posting your public key was clearly the right thing to do.  I
     have noticed; however, that people have posted their public key
     along with a signed message before [there was a discussion on mangled,
     signed plaintext] and thought I would mention this to anybody who
     thought they were using infallible methods or authentication.

     I must urge everybody not to accept any key from a source other then
     person to person [or using a fone call to exchange MD5 hashes] unless
     it is signed by smoebody you HAVE exchanged keys with in this way.
     I hope nobody sees a message with a public key attached to it and says,
     "Oh!  There's a key I can add to my keyring", and abandons the entire
     key-exchange method.  TTFN!


     nobody saw
DrZaphod
[AC/DC] / [DnA][HP]
[drzaphod@ncselxsi.uucp]
Technicolorized





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc Horowitz <marc@MIT.EDU>
Date: Wed, 23 Dec 92 13:36:28 PST
To: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Subject: Stripping signatures (was Re: Remailers)
In-Reply-To: <ywm8VB8w165w@spectrx.saigon.com>
Message-ID: <9212232135.AA00768@deathtongue.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain


I think that signatures should be kept.  If you really want to be
anonymous, you have bigger things to worry about than your sig showing
up or not.

And if I want to build a pseudonymous identity for myself, I might
want to have a sig for that identity.  I wouldn't want the remailers
stripping that out.

Perhaps it would make sense to have a header field which indicated if
the sig should be kept or not.

		Marc




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dmandl@shearson.com (David Mandl)
Date: Wed, 23 Dec 92 14:49:48 PST
To: cypherpunks@toad.com
Subject: Interview with Tim May on WFMU
Message-ID: <9212232149.AA23069@tardis.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


For interested cypherpunks (or anyone else) in the NYC area, I'm going
to be interviewing Tim May on my radio show this Saturday.  The show's
on WFMU (East Orange, NJ), 91.1 FM, from noon-3:00.  Tim'll be on starting
at 2 PM.

   --Dave.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Wed, 23 Dec 92 14:31:14 PST
To: jwn2@qualcomm.com (John W Noerenberg)
Subject: Re: Signing ascii text
In-Reply-To: <9212231707.AA03963@harvey>
Message-ID: <9212232230.AA21068@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> >Canonical Text has a CR and LF at the end of each line.
> Which RFC are you referring to?  

I am not aware of any single RFC that defines this, but every RFC
that I have read, if it mentions end-of-line at all, it is defined
as, or assumed to be, a carriage return followed by a newline.

Even in cases where the native representation is different, it
is converted to this format before transmission through the net,
and then converted back.  This is in some RFC-s referred to 
as "internet tradition", or "NetAscii".

This is similar to the Network Byte Order.  No matter what order
your machine stores bytes (little/big endian), it gets converted
to one standard format.

It is also referred to as "NVT Standard".

The only mention of a different end of line convention is in
relation to EBCDIC, which has an explicit newline <NL> character.

Here are excerpts from various RFCs that deal with, or mention, 
use of CRLF at the end of lines:


Request For Comments: 1078                                       SRI-NIC
                 TCP Port Service Multiplexer (TCPMUX)

   A TCP client connects to a foreign host on TCP port 1.  It sends the
   service name followed by a carriage-return line-feed <CRLF>.  

   acknowledgment, immediately followed by an optional message of
   explanation, terminated with a <CRLF>.  If the reply was positive,

Request for Comments: 1123                             R. Braden, Editor

       Requirements for Internet Hosts -- Application and Support

              To allow interoperability between arbitrary Telnet clients
              and servers, the Telnet protocol defined a standard
              representation for a line terminator.  Since the ASCII
              character set includes no explicit end-of-line character,
              systems have chosen various representations, e.g., CR, LF,
              and the sequence CR LF.  The Telnet protocol chose the CR
              LF sequence as the standard for network transmission.

Request for Comments: 1184                             D. Borman, Editor

                         Telnet Linemode Option

   line should be transmitted with "CR LF" as the line terminator.  When
 
   responsible for doing all output processing.  Specificly, it should
   send "CR LF" when it wants the "newline" function

Request for Comments: 1204                                        D. Lee

                     Message Posting Protocol (MPP)

      USER <SP> <username> <CRLF>
      PASS <SP> <password> <CRLF>
      DATA <CRLF>
      NOOP <CRLF>
      QUIT <CRLF>

      354 Enter mail, end with <CRLF>.<CRLF>

Request for Comments: 1288           Center for Discrete Mathematics and

                  The Finger User Information Protocol

   Any data transferred MUST be in ASCII format, with no parity, and
   with lines ending in CRLF (ASCII 13 followed by ASCII 10).  

Request for Comments: 1312                               Crynwr Software

                        Message Send Protocol 2

		  New lines should be represented using the usual
		  Netascii CR + LF.  (Following the Internet tradition,
		  a server should probably be prepared to accept a
		  message in which some other end-of-line convention is
		  followed, but a conforming client must use CR + LF.)

     NWG/RFC# 561                   AKB KP RST JEW 5-SEP-73 11:19  18516
     Standardizing Network Mail Headers           RFC 561 / NIC 18516

        Formal Syntax:                                               

           <mailtext>    ::= <header> <CRLF> <message>               
           <headeritem>  ::= <item> <CRLF>                           

           <message>     ::= <line> <CRLF> ! <line> <CRLF> <message>
                                                                    
           <line>        ::= a string containing any of the 128 ASCII
                             characters except CR and LF            
           <word>        ::= a string containing any of the 128 ASCII
                             characters except CR, LF, and SP       
           <CRLF>        ::= CR LF                                  
           <SP>          ::= space                                  

   RFC 821
                                    
                     SIMPLE MAIL TRANSFER PROTOCOL

            MAIL <SP> FROM:<reverse-path> <CRLF>

            RCPT <SP> TO:<forward-path> <CRLF>

            DATA <CRLF>

         SEND <SP> FROM:<reverse-path> <CRLF>
         SOML <SP> FROM:<reverse-path> <CRLF>
         SAML <SP> FROM:<reverse-path> <CRLF>
         HELO <SP> <domain> <CRLF>
         QUIT <CRLF>

         The SMTP commands define the mail transfer or the mail system
         function requested by the user.  SMTP commands are character
         strings terminated by <CRLF>.  The command codes themselves are
         alphabetic characters terminated by <SP> if parameters follow
         and <CRLF> otherwise.

     RFC #  822


                        STANDARD FOR THE FORMAT OF
                        ARPA INTERNET TEXT MESSAGES


          A message consists of header fields and, optionally, a body.
     The  body  is simply a sequence of lines containing ASCII charac-
     ters.  It is separated from the headers by a null line  (i.e.,  a
     line with nothing preceding the CRLF).


     field       =  field-name ":" [ field-body ] CRLF

     field-body  =  field-body-contents
                    [CRLF LWSP-char field-body]


        Each header field may be represented on exactly one line  con-
        sisting  of the name of the field and its body, and terminated
        by a CRLF;

Request for Comments: 959                                    J. Reynolds

                      FILE TRANSFER PROTOCOL (FTP)

            In accordance with the NVT standard, the <CRLF> sequence
            should be used where necessary to denote the end of a line
            of text.  (See the discussion of file structure at the end

               process will interpret appropriately.  <CRLF>, in exactly
               this sequence, also denotes end-of-line.

         the FTP implementation should use the end-of-line sequence,
         <CRLF> for ASCII, or <NL> for EBCDIC text files, as the

      For the purpose of standardized transfer, the sending host will
      translate its internal end of line or end of record denotation
      into the representation prescribed by the transfer mode and file
      structure, and the receiving host will perform the inverse
      translation to its internal denotation.  

      End-of-line in an ASCII or EBCDIC file with no
      record structure should be indicated by <CRLF> or <NL>,
      respectively.  

            information.  The data will be transferred in ASCII or
            EBCDIC type over the data connection as valid pathname
            strings separated by <CRLF> or <NL>.  (Again the user must

Request for Comments: 977                   Phil Lapsley (U.C. Berkeley)

                     Network News Transfer Protocol
                                    

   Each command line must be terminated by a CR-LF (Carriage Return -
   Line Feed) pair.

   that indicates that text will follow.  Text is sent as a series of
   successive lines of textual matter, each terminated with CR-LF pair.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Russell Earl Whitaker <whitaker@eternity.demon.co.uk>
Date: Wed, 23 Dec 92 16:03:21 PST
To: cypherpunks@toad.com
Subject: Forwarded article.
Message-ID: <7595@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain



This article was forwarded to you by whitaker@demon.co.uk (Russell Earl Whitaker):

--------------------------------- cut here -----------------------------

Newsgroups: demon.security
From: twillis@pintu.demon.co.uk (Tom Willis)
Path: eternity.demon.co.uk!demon!pintu.demon.co.uk!twillis
Subject: Attempt at a signing policy
Distribution: world
Organization: DGA Ltd
X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
Lines: 122
Date: Tue, 15 Dec 1992 23:46:16 +0000
Message-ID: <724463176snz@pintu.demon.co.uk>
Sender: usenet@demon.co.uk

I would welcome any comments on the following, as a signing policy.
What do you think?


-----BEGIN PGP SIGNED MESSAGE-----

This is my policy for signing keys
==================================
(dated 12th December, 1992 1992-12-12)

- --Type bits/keyID   Date       User ID
- --pub  1024/6AD0D1 1992/10/24  Tom Willis <twillis@pintu.demon.co.uk>
- --          Key fingerprint =  04 D7 B9 24 50 BE B2 30  BD 23 1A 98 B5 01 F1
 46
- --                             Tom Willis <GBR55N55@IBMMAIL>
- --                             Tom Willis
- --              </G=WilliTL/S=Willis/PRMD=IBMMAIL/ADMD=IBMX400/C=GB/>
- --                             Tom Willis <100042.446@Compuserve.com>
- --                             Tom Willis
- --              </CN=Tom Willis/OU=HQ/O=DGA+C=GB/@DGA@Notes>

Introduction
- ------------

It is my intention that you should be able to trust my signature on  any
key that you see.  However, what you mean by trust and what I mean by it
may differ.   In overview, I  will only sign  keys that I  have received
directly from an individual  that claims to own  the key, and that  I am
confident does so.   My confidence is based  upon the policy I  maintain
for signing keys.

Policy
- ------

1.  I will only sign a key that I have received physically during a
    face-to-face meeting with the person claiming to own the key.

2.  I will only sign a key once the claimed key-owner has proved to
    me that they possess the secret key corresponding to the public
    key that they have given me.

3.  I will only  sign a key/ID  pair that I  believe identifies the
    person claiming to own the key.

4.  I do not  claim to have  verified that the  name the person  is
    using is  actually their  own legal  name; I  accept reasonable
    aliases/handles but require that I am confident that the person
    regularly uses the name given in public.

5.  I do not  claim to know  that the key  owner is trustworthy  in
    signing keys, and is not an agent provocateur.

The obvious ones:

6.  I will not allow my secret key and password to fall into anyone
    else's hands.

7.  If I find that my secret  key has been compromised, I shall  do
    my best to  distribute a compromise  certificate to anyone  who
    has received a key with my signature.

Notes on Policy
- ---------------

1.  I will accept keys  presented on paper or  electronically (e.g.
    on diskette), but the key  must have been handed over  during a
    personal meeting with the (claimed) key-owner.

2.  To satisfy me  that the claimed  owner actually *does*  possess
    the secret  key, they  must return  to me  a sequence  of bytes
    (chosen by me) signed with their secret key and encrypted  with
    my public key.

    For example,  if I  meet someone  I do  not know  well, and  we
    exchange keys, I will not sign their key until I have sent them
    a sequence of text bytes (e.g. an item in radix-64 form  signed
    by my key),  and they have  returned the same  item to me  in a
    message that is signed and  encrypted, and I have checked  that
    my  original   `challenge'  and   the  returned   response  are
    *identical*, and that the  message signature agrees with  their
    public key that I posssess.  (Otherwise, the physical  exchange
    could well prove nothing about the person involved except  they
    possess the public key of the person they are claiming to be.)

3.  My signature  says that  the key  and the  associated ID that I
    sign belong together, so  far as I can  tell.  In order  not to
    mislead you, I won't sign  key/ID pairs that look wrong  to me.
    For example, I wouldn't sign  even my own father's key,  if the
    ID  said  something  like  `President  of  the United States of
    America'; because he ain't (and I *know* that!).

    If my father's key  also had a (secondary)  ID on it that  gave
    his name as I know it, I *would* sign that association, even if
    another ID is clearly garbage.

4.  I would cheerfully  sign a key/ID  pair, even if  I *knew* that
    the ID was not the real ID of the owner, if it is a  reasonable
    ID.    For  example,  if  my  Mother  had a stage name, I would
    certainly sign her key with that ID; I would also sign her  key
    with her maiden name.  I wouldn't sign her key/ID where the  ID
    wasn't one  I had  ever heard  her use,  though.   Not even  my
    Mother, much as I trust her otherwise!

5.  My best  friend, known  since childhood,  may be  a gonzo  when
    dealing with security; I have no objection to signing his  key,
    but you should not assume  that says anything about whether  or
    not I would trust *his* signature myself!  (It's OK, mate, just
    joking, I trust you *really*...)

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKyqRM6soIBpyatDRAQH96AP/RMa0+MENYZ2EZTHZFiS04mgA40A0ncL5
rpuRePDrhBjAqxN/K5xX9rWWKgxiQgo3OvsY93tjFUZ1mn4ESUEscf57rnXE26cL
B/jEz+Kn4P4en8107ydl5VvZkkqMj3f3Vyfkuu5YN6KX2NIbpVzQgKSrV4Ah8vob
F0GKx8DdsOs=
=O2fB
-----END PGP SIGNATURE-----

--
Tom \/\/illis   | 1. twillis@pintu.demon.co.uk  | Have PGP 2.0 key
DGA Ltd         | 2. GBR55N55@IBMMAIL           | ... will swap
LONDON UK       | 3. 100042.446@Compuserve.com  |


--------------------------------- cut here -----------------------------





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705 wcs@anchor.ho.att.com)
Date: Wed, 23 Dec 92 15:31:40 PST
To: cypherpunks@toad.com
Subject: Re: Signing ascii text
Message-ID: <9212232331.AA20426@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text


The problem with signing whitespace-compressed canonicalized text isn't the 
loss of readability, since you can send the non-canonicalized version for humans.
The problem is that sometimes the white space IS significant
	Project-Schedule        1992   1993  1994
	Phase 1                   X
	Phase 2                          X
	Phase 3				       X
would acquire the same signature if you moved the Xs to different columns.
If we're going to treat white space in text as significant, we made need
to adopt a scheme such as MIME's =xx content-transfer-ncodings;
Otherwise we need to declare by fiat that white space is not significant 
unless protected by an encoding.
		Bill Stewart



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Richard Childers <rchilder@us.oracle.com>
Date: Thu, 24 Dec 92 00:28:11 PST
To: cypherpunks@toad.com
Subject: 1993 RSA Data Security Conference
Message-ID: <9212240826.AA23973@rchilder.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain




( I'm sitting here, waiting for Sequent to call back after a late-night
  systems crash ... may as well put the time to some good use ... )-:


Looking for computer & communications products that have real public-key
security built in ... maybe interested in enhancing your _own_ products
with encryption and authentication technologies ... or just want to know
what all the excitement is about ?

RSA invites end users, developers and OEMs to attend the

		1993 RSA Data Security Conference

The only conference and expo devoted exclusively to public-key cryptography.

Talk to colleagues, developers, potential customers and experts from the
best and the brightest companies in the security business. Get the real
story on licensing, standards, algorithm strength, and export restrictions.
See the newest public-key products from the biggest vendors in the computer
industry. Attend tutorials on secure application design and developing
with RSA's cryptography toolkits, such as TIPEM and the new BSAFE 2.0.
Find out how others in your line of business are using RSA technology to
differentiate their products and improve their own internal security.

The conference is being underwritten by RSA Data Security, Inc., and is free
to all attendees and exhibitors. Interested ? Registration is extremely
limited, and is first-come, first-served.

Call RSA today and reserve your seat. 415/595-8782, ask for Conference
Registration.

		Thursday January 14th : Conference

	   Friday January 15th : Tutorials & Exposition

		  Redwood Shores, California







-- richard

=====
-- richard childers		rchilder@us.oracle.com		1 415 506 2411
         oracle data center  --  unix systems & network administration

 "If Life is a drama, then, surely, the hardest parts go to the most skillful."




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: mark@coombs.anu.edu.au (Mark)
Date: Wed, 23 Dec 92 13:19:37 PST
To: cypherpunks@toad.com
Subject: Re: Signing ascii text
Message-ID: <9212232118.AA01592@coombs.anu.edu.au>
MIME-Version: 1.0
Content-Type: text/plain


>Date: Wed, 23 Dec 92 11:02:31 PST
>From: Eric Messick <eric@parallax.com>

>It would canonicalize a file by
>turning all sequences of white space into a single space and trimming
>leading and trailing whitespace from the file before computing the
>hash.

If the message contained a table of figures formatted and seperated with
spaces then that method would destroy the readability of the table. If the
file was processed to change tabs to spaces, according to your .exrc
settings, then the message would be cleared of any ambiguities from
differing lengths of tabs. This is assuming none of the forwarding mail
systems between parties replaces a sequence of spaces with a single tab.
I personally havent seen such behaviour, nor would I expect it. It makes
too many (bad) assumptions.

Trailing spaces should of course be nulled as they serve little purpose.

Mark
mark@coombs.anu.edu.au




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: sdw@sdwsys.lig.net (Stephen D. Williams)
Date: Thu, 24 Dec 92 06:09:09 PST
To: eric@parallax.com (Eric Messick)
Subject: Re: Signing ascii text
In-Reply-To: <9212232303.AA26569@parallax.com>
Message-ID: <9212241403.AA26014@sdwsys.lig.net>
MIME-Version: 1.0
Content-Type: text/plain


...
> 
> The important part here is that the collapsing of whitespace would
> only affect the message digest, not the text as seen by the user.  Two
> texts which read the same, but differ in whitespace, would have the
> same signature.  If you recieved both files, you could see the
> difference in spacing, yet the same signature would be valid for both
> files.  The main vulnerability is that a message whose meaning is
> partially encoded it its whitespace (like an ascii graphic, map, or
> chart) could have its meaning altered, without affecting the validity
> of the signature.  Clearly one would not want to use this signature
> method on such texts.  It would be a good feature for the signature
> algorithm to warn the user if it detects a pattern of whitespace that
> might convey information.  I am not sure how to detect this reliably,
> though.

How about two signatures, verbatim and space-collapsed.

That way if the latter was valid but the former was not, you would
know that spacing was altered but other info remained valid.

sdw



From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: miron@extropia.wimsey.com (Miron Cuperman)
Date: Thu, 24 Dec 92 02:11:40 PST
To: cypherpunks@toad.com
Subject: Belated holiday travel
In-Reply-To: <9212180907.AA07411@portnoy.MIT.EDU>
Message-ID: <1992Dec24.092516.2347@extropia.wimsey.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain


I'll be flying into LA on the 5th of Jan, staying in Santa-Barbara
and flying out of LA on the 14th.  If anyone is interested in swapping
public keys and/or just getting together, please let me know.

My house is protected. ;)

-- 
        Miron Cuperman <miron@extropia.wimsey.com> | NeXTmail/Mime ok
                       <miron@cs.sfu.ca>           | Public key avail
        AMIX: MCuperman                            |
cyberspacecomputingcryptoimmortalitynetworkslaissezfaire




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 28 Dec 92 00:54:14 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Miron's Remailer
Message-ID: <k5RawB6w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

I tried Miron Cuperman's remailer, which requires encrypted input.
I noted happily that my automatic signature did not echo back, because
it was not part of the encrypted text.

I was going to ask how this effected ARA, but Miron has already
recognized this problem and proposed a solution.

Except for messages to be posted to newsgroups or sent to lists,
message bodies are likely to be encrypted with the public key
of the recipient. Certainly anyone sending or posting an ARA
should also post an "anonymous" public key for the body of the
reply. (An anonymous public key is just a key with some nom de
plume in the User ID field).

Another topic: signed plaintext.  Miron's signed plaintext failed
the signature check here.  This is probably because my editor
eliminates trailing blanks. Someone here pointed out that
a trailing blank in a blank line may be introduced by an
ASCII upload. Until PGP is fixed to eliminate trailing blanks
in text, I may have another solution.

The editor on this WAFFLE system has an ability to UPLOAD files
using (for example) ZMODEM. I have modified the Telix SLT file I
use so I have a choice of ASCII or Zmodem upload. Proof of pudding
is in eating.  Check the signature on this upload, which contains
several blank lines.  I will be checking with you when I get the
echo back.

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBKzi5VN4nNf3ah8DHAQH+dAP/eD8opIrO19Led9SwNDIX6LOiZqlmpOZV
jX/30PJ50/1n8BlYowvDaDcPSp6R0JNggYcOg17G88MrpYHq0ODxw0w/wXd+1MHS
Twhu2HUy03tJFmbOOX+kVlk2N2RFGag3063QV6SaweVMLg9DEMyPDHiSbeCTxFR7
RapDSiNV/w4=
=imWV
-----END PGP SIGNATURE-----

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dmandl@shearson.com (David Mandl)
Date: Thu, 24 Dec 92 06:58:20 PST
To: cypherpunks@toad.com
Subject: Interview with Tim May on WFMU
Message-ID: <9212241449.AA25477@tardis.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


Yipes.  I got a whole bunch of (advance) requests for tapes of the
interview, so I'm posting this to the group to make things a bit
easier for myself...

I'll be more than happy to send copies to anyone for the cost
of postage and the blank tape.  I'll also be sending a copy to
Tim, so if it's easier, you can try to get him to dupe it for you.
Of course, being a worrywart, I'll hold off until Monday to confirm
that the thing went off without a hitch.  I'll post to the group
then and let you know.

   --Dave.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: pmetzger@shearson.com (Perry E. Metzger)
Date: Thu, 24 Dec 92 08:30:25 PST
To: cypherpunks@toad.com
Subject: Re: Signing ascii text
Message-ID: <9212241539.AA23696@maggie.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain



> From: mark@coombs.anu.edu.au (Mark)
> 
> >Date: Wed, 23 Dec 92 11:02:31 PST
> >From: Eric Messick <eric@parallax.com>
> 
> >It would canonicalize a file by
> >turning all sequences of white space into a single space and trimming
> >leading and trailing whitespace from the file before computing the
> >hash.
> 
> If the message contained a table of figures formatted and seperated with
> spaces then that method would destroy the readability of the table.

The notion was NOT that the text would be altered in transmition, but that
the signature would be computed on canonicalized text. No one was proposing
hacking tabs, only that a version of the text with hacked tabs be used
to compute the checksum as by hacking the tabs we will have an easy to
produce canonical format. The concern Eric presented was that this would allow
two files containing substantially different content from a computer's point
of view to MD5 the same, but he noted that this isn't a problem in
practice because humans don't get much information out of the presense of
multiple spaces versus one space.

Perry




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
Date: Thu, 24 Dec 92 09:57:49 PST
To: sdw@sdwsys.lig.net
Subject: Signing ascii text
In-Reply-To: <9212241403.AA26014@sdwsys.lig.net>
Message-ID: <9212241705.AA00221@orchard.medford.ma.us>
MIME-Version: 1.0
Content-Type: text/plain


I don't think space-collapsed signatures make any sense; they're only
going to mess up

If you're going to do any canonicalization, do either exactly what PEM
does, or canonicalize tabs and trailing spaces out of the message at
posting time.  Then do the same canonicalization on the receive end
before the signature is verified.

If a message transfer path is still "lossy", stop using the unencoded
body and just live with radix64 encoding.

				- Bill






From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: rsteiger@denver.cba.du.edu (Todd_Steigerwald)
Date: Thu, 24 Dec 92 12:26:56 PST
To: cypherpunks@toad.com
Subject: Re: Destroying Data
Message-ID: <9212242020.AA13761@ denver.cba.du.edu >
MIME-Version: 1.0
Content-Type: text/plain





>	Consider also the technique used in the Norton Utilities
>	program "Diskwipe" which takes a /g switch which "Follows
>	certain government rules for wiping". I can't find the manual
>	but I think it specifies how many repetitions are used and
>	different values to write in each. 


	The Norton Utilities Wipedisk /g does three passes writing  
1's and then 0's, it follows this with the hex 'FF'.  This shoud  
pretty much remove any residual traces of the data previously held on  
the disk.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 24 Dec 92 11:13:41 PST
To: pmetzger@shearson.com
Subject: significance of spaces
Message-ID: <9212241912.AA15402@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> of view to MD5 the same, but he noted that this isn't a problem in
> practice because humans don't get much information out of the presense of
> multiple spaces versus one space.

This is true for most text, like this message.  But sometimes people
send messages where spacing is VERY important:

This is especially true of tables such as this one:


Name	Yes	No

Smith	X
Jones		X
Brown		X
Xyzzy	X

If the signature algorithm disregarded spaces, the X's could be moved
from one column to the other without affecting the signature.

I know that this information COULD have been represented as:

Smith	Yes
Jones	No
Brown	No
Xyzzy	Yes

But sometimes people use the other format.  Another solution is to
surround all significant spaces with some other character, such 
as the vertical bar:

|Name	| Yes	| No	|

|Smith	| X	|	|
|Jones	|	| X	|
|Brown	|	| X	|
|Xyzzy	| X	|	|

If this were done, an X could not be moved without affecting the signature
even if tabs/spaces were insignificant.

The point is that if whitespace is made insignificant, the users must be
educated about it, and trained to use one of the two last formats
instead of the first one.  


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 28 Dec 92 00:54:17 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Re: Secret PGP Keys
Message-ID: <s1kewB3w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


In response to Anton Sherwoods Dec 22 posting:
 
    Here's a lame question from a beginner who hasn't even downloaded
    PGP:
 
    Am I supposed to memorize my private key, lest cops beat down the
    door while I'm out?
 
You would find it difficult to memorize your PGP secret key.
It's 384-1024 bits assigned by PGP when it generates a key pair.
There's not even any provision for manually entering your secret
key. It's only useful in electronic form, on your disk. Which is not
to say it may be useful to store it on a floppy at some location
removed from the computer in some situations.
 
However, PGP has added something called a "pass phrase" which you
can assign to your secret key when you generate a key pair. The
pass phrase is optional, but strongly advised. Since you make it up,
it should be easy to memorize, so *don't* write it down or store it
anywhere where unfriendly forces could find it.
 
PGP uses the pass phrase you assign to encrypt the stored version of
the secret key it generates for you.  The pass phrase is therefore
required (and is prompted for) before the secret key can be used to
either decrypt incoming mail or sign outgoing mail.
 
This is your defense against the cops beating down the door.  They
will find the (encrypted) secret key on your disk.  The pass phrase is
in your head and you have a right to remain silent; use it.
 
There might be some situation where a judge could order you to give
up the pass phrase: you are granted immunity from criminal prosecution
(but you don't want to incriminate your friends) or in a civil
discovery action.  In this case, just claim to have forgotten the
pass phrase in the stress of the situation. Stick to that; no-one
can prove otherwise.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 28 Dec 92 00:53:59 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Re: Signing ASCII text
Message-ID: <L2kewB4w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


I was able to verify Hal Finney's signed plaintext message posted here
on Dec 23 with a good signature.  Hal says he prepared the original
plaintext with no trailing blanks.  The editor I use removes trailing
blanks whenever it saves text to disk.  So there could have been
trailing blanks in the plaintext I received (which would have spoiled
the signature match) put there by ASCII uploading (of blank lines) or
otherwise and I wouldn't know it.
 
I can't really fault mailers that remove trailing blanks; they are
trying to avoid consuming bandwidth with null information. I think
the answer is a change to PGP to remove trailing blanks anytime
-t is active. I have written to Branko to suggest this, but his
response was somewhat lukewarm.  Perhaps he would change his mind
if he received the same suggestion from several individual PGP users.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: edgar@spectrx.saigon.com (Edgar W. Swank)
Date: Mon, 28 Dec 92 00:54:12 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Re: remailer signature suppression
Message-ID: <N3kewB6w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


Marc Horowitz wrote on Dec 23:
 
    I think that signatures should be kept.  If you really want to be
    anonymous, you have bigger things to worry about than your sig
    showing up or not.
 
I don't follow Marc's logic here. If the wrong sig shows up, it
obviously negates all other precautions taken in using remailers, etc.
 
    And if I want to build a pseudonymous identity for myself, I might
    want to have a sig for that identity.  I wouldn't want the
    remailers stripping that out.
 
The problem is if you want to send a mixture of anonymous and
regular mail. This involves changing the "sig" on the fly; difficult
to do reliably with an automatic script. With loss of anonymity the
consequence of the wrong sig appearing with either anonymous or non-
anonymous messages.
 
    Perhaps it would make sense to have a header field which indicated
    if the sig should be kept or not.
 
This might be a good compromise.  Of course I would prefer the
signature-screen: Yes to be the default.  Also don't forget that
for those of us who can't specify net-headers at will this new
header would also have to be specifiable within text via the ::
convention or otherwise.

--
edgar@spectrx.saigon.com (Edgar W. Swank)
SPECTROX SYSTEMS +1.408.252.1005  Silicon Valley, Ca





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hugh@domingo.teracons.com (Hugh Daniel)
Date: Mon, 28 Dec 92 01:32:42 PST
To: cypherpunks@toad.com
Subject: A solution remailer signature suppression
In-Reply-To: <N3kewB6w165w@spectrx.saigon.com>
Message-ID: <9212280931.AA08065@domingo.teracons.com>
MIME-Version: 1.0
Content-Type: text/plain


  There are very good reasons to build remailers (and all mail tools)
to pass on all the bytes they can, trailing spaces and .sigs included.
  Might I sugjest that we set up the remailers with a feature where it
tests mail sent from its owner to make sure there is no "compromising"
content and that the outer shell verifies correctly, if it fails
either of these tests it is dumped in a file and a note returned to
you saying someings not right.
  This has two good features, first you know that what you send out is
good looking stuff and that if someone complains that its likely the
falut of some machine between the two of you and not you.  Second
this gets folks running remailers everywhere just as part of the
infrastructure of using cryptoware.
  Does this sound like something we can build upon for everyone?

		||ugh Daniel




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Mon, 28 Dec 92 05:58:52 PST
To: exi-essay@gnu.ai.mit.edu
Subject: INFO: Encryption Technology
Message-ID: <9212281358.AA06947@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


The following was written by me in response to David Friedman's request
for an overview of various encryption technologies, what they can do,
and why they are important.

This summary does not discuss any mathematics of this technology, it is
meant for someone that wants to know what it is, and what it can do,
without having to know all the mathematical details.

This message can be stored in the exi-essay ftp archive.

Forwarded message:

PUBLIC KEY CRYPTOGRAPHY -- each person generates two keys, one is
called the public key the other is the private key.  These two are
related in that what is encrypted with one can only be decrypted with
the other.  It is impossible (computationally infeasible) to derive one
knowing the other.  The most popular public key cryptography algorithm
is RSA, which is based on the ease of multiplying large primes, and the
difficulty of factoring the product.

How it is used: you publish the public key, while keeping the private
key to yourself.  Anyone can send a secret message to you by encrypting
it with your public key.  You are the only one that can decrypt the
message, since only you have the private key.

You can reply by encrypting your message with their public key, and
they can decrypt it with their private key.


DIGITAL SIGNATURES -- techniques that are used to verify that a message
claiming to be from you was actually written by you.  To do that, you
compute a "message digest", which is similar to a "checksum" in that it
can be used to check that the message has not been altered.  Then you
encrypt the "digest" with your private key and attach to the message.
Currently the most popular "digest" algorithm is MD5.

To verify a signature:  the person verifying computes the same
checksum, then decrypts the checksum attached to the message.  If the
two match, the message must have been signed by you, since no-one else
has your private key, and could not have generated the signature.


DIFFEY-HELLMANN KEY EXCHANGE --  a protocol by which two communicating
parties can arrive at a secret piece of information that can not be
known to a passive eavesdropper (as in a wiretap), and can not be
recovered from analysis of recorded communication.  This secret piece
of information is usually used as the key for a conventional
cryptography algorithm such as DES or IDEA to encrypt following
communication.

This can be used, for example, for secure telephones.  Two people with
these phones connect through the usual telephone network, push the "go
secure" button, the phones perform Diffey-Hellmann key exchange, and
encrypt the following conversation with the resulting secret key.

Not that these two people did not have to meet in person, or transmit a
key through any other channel.  The key was generated as needed.

After the conversation is finished, both phones erase the key from
their memory.  For the next conversation, a new key is set up.

Someone who has a recording of a wiretap has absolutely no way of
knowing what they key was, and therefore can not decode the
conversation.

This technology makes wiretaps obsolete.


SENDER UNTRACEABILITY -- use of a protocol by which one of a group of
communicating entities can send a public message, while it is impossible
to trace the message to the sender.  This can be used to send messages
anonymously or pseudonymously and untraceably.  One of the protocols
that makes this possible is David Chaum's dc-net protocol, in which
every participant sends some data, and when all the data are combined,
the anonymous message emerges.  This has been called the "cryptographic
ouja board", because a message appears, but it is impossible to find
out who sent it.  If one-time pads are used, this system is
unconditionally secure, which means that even an enemy with an infinite
amount of time and processing power van not deduce the sender from
available information.

Another sender untraceability system is the mix-net, or "remailer"
approach.  In this case, you send your message to a re-mailer, with
encrypted instructions on where to send it.  By sending your message
through a chain of such remailers, untraceability is achieved.  This
depends on the remailers not keeping logs that can correlate incoming
and outgoing messages, or unwillingness to reveal such logs to your
enemy.


RECEIVER UNTRACEABILITY -- a method by which you can retrieve a message
sent to you, without anyone having any way of knowing that you received
the message, or indeed if you received any message at all.

How it works:  anyone wanting to leave a message to you encrypts it
with your public key, and posts it on a "bulletin board".  You download
all the messages from the bulletin board periodically, and see if you
can decrypt any using your private key.

Since everyone downloads all the messages, and THEN attempts to decrypt
them on their own machine, no-one observing the communications link has
any way of knowing who received what message, or even if someone
received any messages at all.  This system, along with the dc-net, can
provide completely untraceable global communications.  It does,
however, require substantial communications bandwidth and storage
capacity.



DIGITAL CASH -- one entity creates some amount of digital "tokens",
which may then be transferred to other people, who can transfer them
between each other, and when they are returned to their creator, he can
not trace the transactions that have occurred, only the total balance of
a person at the end of the set of transactions.

This combines the anonymity and untraceability of cash with the
convenience and efficiency of electronic transactions.  In combination
with the above systems, it is superior to cash since any person can pay
anyone else, anonymously and untraceably, without having to meet in
person.

David Friedman asks: "How can it be used, and why does it matter?"

Each of these technologies by itself can not accomplish much.  But if
all these are put together, any person can send messages to any other
person, or transact business without anyone but the two of them knowing
what occurred, or, even that something at all occurred between these two
persons.

Furthermore, these two people don't need to know anything about each
other, but their public key.  They can be completely anonymous, or use
a pseudonym.

As for why it matters, I include here Timothy C. May's Crypto Anarchist
Manifesto:


The Crypto Anarchist Manifesto

Timothy C. May
tcmay@netcom.com


A specter is haunting the modern world, the specter of crypto anarchy.

Computer technology is on the verge of providing the ability for
individuals and groups to communicate and interact with each other in a
totally anonymous manner. Two persons may exchange messages, conduct
business, and negotiate electronic contracts without ever knowing the
True Name, or legal identity, of the other.  Interactions over networks
will be untraceable, via extensive re- routing of encrypted packets and
tamper-proof boxes which implement cryptographic protocols with nearly
perfect assurance against any tampering. Reputations will be of central
importance, far more important in dealings than even the credit ratings
of today.  These developments will alter completely the nature of
government regulation, the ability to tax and control economic
interactions, the ability to keep information secret, and will even
alter the nature of trust and reputation.

The technology for this revolution--and it surely will be both a social
and economic revolution--has existed in theory for the past decade.
The methods are based upon public-key encryption, zero-knowledge
interactive proof systems, and various software protocols for
interaction, authentication, and verification. The focus has until now
been on academic conferences in Europe and the U.S., conferences
monitored closely by the National Security Agency. But only recently
have computer networks and  personal computers attained sufficient
speed to make the ideas practically realizable. And the next ten years
will bring enough additional speed to make the ideas economically
feasible and essentially unstoppable. High-speed networks, ISDN,
tamper-proof boxes, smart cards, satellites,  Ku-band transmitters,
multi-MIPS personal computers, and encryption chips now under
development will be some of the enabling technologies.

The State will of course try to slow or halt the spread of this
technology, citing national security concerns, use of the technology by
drug dealers and tax evaders, and fears of societal disintegration.
Many of these concerns will be valid; crypto anarchy will allow
national secrets to be trade freely and will allow illicit and stolen
materials to be traded. An anonymous computerized market will even make
possible abhorrent markets for assassinations and extortion. Various
criminal and foreign elements will be active users of CryptoNet. But
this will not halt the spread of crypto anarchy.

Just as the technology of printing altered and reduced the power of
medieval guilds and the social power structure, so too will cryptologic
methods fundamentally alter the nature of corporations and of
government interference in economic transactions. Combined with
emerging information markets, crypto anarchy will create a liquid
market for any and all material which can be put into words and
pictures. And just as a seemingly minor invention like barbed wire made
possible the fencing-off of vast ranches and farms, thus altering
forever the concepts of land and property rights in the frontier West,
so too will the seemingly minor discovery out of an arcane branch of
mathematics come to be the wire clippers which dismantle the barbed
wire around intellectual property.

Arise, you have nothing to lose but your barbed wire fences!


--
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.


David Friedman asks for a brief summary of the present legal/political
attempts and suggestions that have been made to control the
technology.

The FBI has proposed a "Digital Telephony" bill, which would require
all providers of any kind of communications service to build in a
wiretap capability for the government.  Department of State is
restricting the export of any crypto software, claiming that it is a
weapon, and therefore falls under ITAR (International Traffic in Arms
Regulations) rules.  Public Key Partners (PKP) holds the control of
patents that cover RSA, and possibly the very idea of public key
cryptography.  Someone (I can't provide a reference) has proposed that
anyone that uses encryption should be required to register their key
with the Justice Department, so that the text could be decrypted if a
search warrant is issued.  These are all the attempts to control this
technology that come to my mind right now.

The Electronic Frontier Foundation (EFF) can probably provide more
information (e-mail to eff@eff.org).


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Eric Messick <eric@parallax.com>
Date: Mon, 28 Dec 92 11:19:24 PST
To: cypherpunks@toad.com
Subject: Re: Signing ascii text
Message-ID: <9212281831.AA14733@parallax.com>
MIME-Version: 1.0
Content-Type: text/plain



Stephen D. Williams writes:

> How about two signatures, verbatim and space-collapsed.
> 
> That way if the latter was valid but the former was not, you would
> know that spacing was altered but other info remained valid.
> 
> sdw

This seems to be the correct solution to me.  If PGP did this
automatically in text signature mode, then it would be up to the
reciever to decide if spaces were significant or not, and they would
be prompted to think about this when the verbatim signature
verification failed.  If one often recieved messages with mangled
spacing, one could become desensitized to this, but there's not much
to be done about that.

-- eric messick
eric@toad.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: wendtj@jplpost.Jpl.Nasa.Gov (Jeffrey P Wendt)
Date: Mon, 28 Dec 92 12:01:22 PST
To: cypherpunks@toad.com
Subject: TEMPEST companies
Message-ID: <9211287255.AA725572669@jplpost.jpl.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain


          I have recieved information from Veratec re: the product
          Safe`n'Shield, and I have to say that for an inf0 packet,
          they have done a great job.

          The folder comes with 2 sample squares of the Safe`n'
          Shield material, and the specs for their product are as
          follows:
          >-----------------------------------------------------------
          > Shielding Effectiveness of SAFE`N'SHIELDED (R)
          >(in dB Attenuation)
          >___________________________________________________________
          >SAF`N'40 tm             10' x 20' x 8' Room
          >___________________________________________________________
          >    10KHz     1MHz      50MHz     400MHz    1GHz
          >-----------------------------------------------------------
          >    >100       76        53         57       62
          >___________________________________________________________

          >___________________________________________________________
          >SAF`N'60 tm              8' x 8' x 8' Room
          >___________________________________________________________
          >    10KHz     1MHz      50MHz     400MHz    1GHz
          >-----------------------------------------------------------
          >    >100      N/T*       67         72       87
          >___________________________________________________________

          >___________________________________________________________
          >SAF`N'80 tm              8' x 8' x 8' Room
          >___________________________________________________________
          >    10KHz     1MHz      50MHz     400MHz    1GHz
          >-----------------------------------------------------------
          >    >100      >81        100        90       90
          >___________________________________________________________

          In addition to some general notes and a customer list, they
          provide a 25 page booklet on construction techniques; both
          new and existing.  The material is very thin, about the same
          weight and feel as good bond paper.  The manufacturer states
          that this material meets the NSA 65-6 spec using this
          nonwoven material as the priamary shield.

          The material is applied just like wall paper, with comercial
          wallpaper glue, and from a construction point of view this
          stuff looks like you could do an 8x8x8 romm in a few hours.
          Alas, I did not recieve a price list on the material, but I
          am sure it will be a hell-of-a-lot cheaper that buying
          TEMPEST certified computers, and best of all...you don't
          have to register a damn thing ;-)).

          The address is:  Veretec
                           Long Meadow Road
                           Tuxedo, New York 10987
                           (919) 577-7447




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: dmandl@shearson.com (David Mandl)
Date: Mon, 28 Dec 92 12:54:50 PST
To: cypherpunks@toad.com
Subject: Radio Interview w/Tim May
Message-ID: <9212282013.AA05024@tardis.shearson.com>
MIME-Version: 1.0
Content-Type: text/plain


OK, folks, the interview went off beautifully (thanks Tim).
As mentioned earlier, if anyone wants a copy of the tape,
I'll be happy to send one.  Unfortunately, I'm going to be
a little slow making copies because my cassette deck is 
crippled at the moment, so be patient.  Email me if you're
interested.

** Important request: Is there a kind soul out there who would
be willing to transcribe the interview (~40 minutes total)???
I just don't have the time.  If you can do it, I will mail you 
a copy of the tape gratis (total value: $1.50 + postage!).

   --Dave.




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: eric@parallax.com (Eric Messick)
Date: Tue, 29 Dec 92 14:06:03 PST
To: cypherpunks@toad.com
Subject: Self Addressed Stamped Envelopes
Message-ID: <9212292048.AA19819@parallax.com>
MIME-Version: 1.0
Content-Type: text/plain



||ugh and I were talking (over an unsecure phone line :-) last night
and came up with an interesting idea.

The problem:  anonymous replies.

Under the current system, the solution is simple:  create an
`envelope' which implements a path back to you.  You include this
envelope with your outgoing message, and the respondant places the
envelope at the front of any messages to be sent back to you.  The
envelope is a nested encrypted set of Anon-To: lines that remailers
strip off as the message is routed back to you.

This system has at least two weaknesses for future use, however.  The
most serious is that the body of the reply is not altered by the
remailers, allowing the message to be more easily traced.  The second
is that there is no provision for remailers to charge for the service.
If postage is included in the envelope itself, it becomes a single use
device; it is useless for posting to a newsgroup, for example.

Both of these problems can be solved by having each remailer forward
the message *with*postage*due*.  What that means is that the remailer
encrypts the message before sending it on, and saves the key used in
an account file along with a message id and the amount due.  The body
is thus altered on each hop, complicating the process of tracing the
message.  You also are unable to read the message until you have paid
the postage on it, which you do by sending a message to yourself via a
similar envelope.  That message contains stamps which get removed at
each step by the remailers, and replaced with the necessary key for
reading the mail.  When you recieve the second message back, you have
the necessary info to read the first, and have paid for its delivery.

A variation would allow the respondant to include the necessary
postage (you need to specify how much, thus compromising at least the
hop count of your route).  To keep each remailer's postage seperate,
key pairs could be generated, with the public portion kept outside the
envelope, and the secret portion sealed within the envelope, openable
only by a single remailer.  The postage would be wrapped up in
successive keys as specified on the outside of the envelope.  The
envelope would then specify the keys to be used by each remailer to
transform the body.

All of this requires defining a message as containing an envelope and
a contents.  The envelope must be able to specify how the contents are
to be encrypted at each hop. Perhaps the envelope could be placed in
the header of the message as a single field.

Details still need to be worked out.  Comments?

-- eric messick
eric@toad.com




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: hugh@domingo.teracons.com (Hugh Daniel)
Date: Tue, 29 Dec 92 16:16:27 PST
To: cypherpunks@toad.com
Subject: Crypto Bus to Winter Usenix in San Diego
Message-ID: <9212300014.AA08503@domingo.teracons.com>
MIME-Version: 1.0
Content-Type: text/plain


  [The Bays (SF and Monteray) area CypherPunks are thinking of takeing
a bus to Usenix, if you don't live near the Bays you might want to
ingore this message.]
  Ok a bus will cost about $2500 round trip (keeping the bus in the
parking lot for the three or four days of Usenix).  If we get 20
people to ride the bus the cost per person is about $125, if we get 30
folks the cost per person is about $83, both of these are ROUND trip
prices.
  If you are interested in rideing the Crypto Bus I need a commitment
from you as to a price point.  If you are willing to ride the bus at
say, $115, then send me <hugh@toad.com> (and NOT the group!) email
saying what your price point is and if we get enough people then we
will do a bus.  I need as many commitments as possable this week
(before the new year) to get a bus reserved, if you don't read this
before the new year then respond on monday or tuesday next week.  Late
commers will be taken on a first come first served basis, if there are
enough folks to do a bus in the next few days.
  Bus will leave SF Bay area and make a day trip into Mexico, and
return to SF Bay area.  We get to stop and eat where we want!  If you
are willing to leave early Sunday, Monday, Thursday or Friday so that
we can do a long streach of Mexico coast or something please include
that in your email to me.
  If you have questions please feal free to contact me.

		||ugh Daniel
		Just a 555 acting as a Bus Driver...





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Date: Tue, 29 Dec 92 15:10:54 PST
To: cypherpunks@toad.com
Subject: Re: Self Addressed Stamped Envelopes
Message-ID: <9212292310.AA23801@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


If the remailer is willing to keep some state information around for
a limited time, auto-reply can be even simpler:  when a remailer
forwards mail, it saves the return address and replaces it with a 
unique ID for that mail, which it creates and saves.  The recipient
can just use the 'reply' command of his mailer.  When the remailer
gets mail with this unique ID, it plugs in the old return address, 
encrypts the message to the new destination, and sends it along,
retracing its original path.

This does provide a weaker security guarantee than if the remailer
_throws away_ the correspondence with input and output, though, so
a slightly more complicated alternative is probably better.


-- Marc Ringuette (mnr@cs.cmu.edu)





From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Tue, 29 Dec 92 16:33:58 PST
To: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Subject: Anonymous Reply Capability (re: Self Addressed Stamped...)
In-Reply-To: <9212292310.AA23801@toad.com>
Message-ID: <9212300033.AA07511@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


> unique ID for that mail, which it creates and saves.  The recipient
> can just use the 'reply' command of his mailer.  When the remailer
> gets mail with this unique ID, it plugs in the old return address, 
> retracing its original path.

For best security with a mix-net remailer, it should immediately
forget where a message came from.  

So if you want anonymous reply capability, the remailer could create
that unique id, but instead of associating it with a return address,
associate it with a public key (transmitted along with the message).

Then when someone sends a reply, the remailer would encrypt it with
the public key, and broadcast it.  You monitor the broacasts for
ones with public keys that match private keys you have.



--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Wed, 30 Dec 92 13:36:33 PST
To: cypherpunks@toad.com
Subject: Return addresses
Message-ID: <9212302111.AA09802@nano.noname>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Eric Messick has an interesting idea in his "postage due" anonymous
addresses, where the forwarders would encrypt the message contents as
it passed through, and then the receiver would have to pay them to get
the message decrypted.

Chaum's idea was that the message contents would be encrypted at each
step, as Eric suggests, but Chaum would have the encryption key be
part of the anonymous address, created by the same person who made the
anonymous address.  The idea would be, after decrypting the incoming
message, the remailer would see something like:

	Anon-To: <next destination>
	Encrypt-With: <some DES or IDEA key>

It would then encrypt the message "contents" (but not the "envelope",
as Eric points out) using the specified key.  When the owner of the
anonymous address received the message, he would decrypt it using the
chain of "Encrypt-With" keys that he put into the anonymous address.

This does not support Eric's feature of allowing remailers to charge
for anonymous addresses, but it does provide more security than the
current remailers by changing the message contents at each step.

Hal
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBK0IQLqgTA69YIUw3AQHqawQAozCAXrHB1+dksB2fQKeqIoY530340chd
PZlznNGv0wp5gZdIJnFqJ/40scABHjuMc7B7e9QnUglMm1j59b6ZJOGON8kOaYsm
J19vsCOWEWuQhFtMl6oC4hXxPtjZ1BOdm8lr+RQ7KZlpBTe4eusoEMaV5zMMk1TI
vkAT6A4YZ5o=
=DZE1
-----END PGP SIGNATURE-----




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: gnu@cygnus.com
Date: Wed, 30 Dec 92 23:52:29 PST
To: cypherpunks@toad.com
Subject: Random number generators
In-Reply-To: <199212310057.AA02517@eff.org>
Message-ID: <9212310751.AA21888@cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain


>                       MONTE CARLO TECHNIQUES,
> widely used in computer simulations of physical systems, entail the
> wholesale generation of random numbers.  A new study by scientists at
> the University of Georgia (Alan Ferrenberg, 404-542-8460) shows that
> even the most advanced random-number generators are biased under
> certain circumstances (A.M. Ferrenberg et al., 7 Dec. Physical Review
> Letters).  Using one state-of-the-art program, the Marsaglia-Zeman
> random-number generator, Ferrenberg discovered that a simulated
> performance of the two-dimensional Ising model (which models the
> behavior of a plane of neighboring spins) did not agree with the
> results when calculated exactly by mathematical methods.  He traced the
> discrepancy to the random- number generator.  Other generators tried
> had differing faults.
> (Science News, 19 & 26 Dec.)

Can someone get the paper(s) and/or talk to the researcher?  Does he
have any programs he can throw into the pot for generating or testing
random numbers?

	John




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: whitaker@eternity.demon.co.uk (Russell E. Whitaker)
Date: Thu, 31 Dec 92 07:51:30 PST
To: cypherpunks@toad.com
Subject: MEETING: Cypherpunks UK (2nd)
Message-ID: <7971@eternity.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


2nd Meeting, Cypherpunks UK
---------------------------

Chris Tame, of FOREST and the Libertarian Alliance, has generously
offered the use of the meeting room at his offices for our gathering,
Sunday, 10 January 1993, from 1300 onwards, at:

  FOREST
  4th Floor
  2 Grosvenor Gardens
  London   SW1W 0DH
  071-823-6550

This is just around the corner from Victoria Station, at the end of the
mansion block near Hobart Place.  There's a dark green cabbie shelter
across the street from the entrance, and some British Telecom payphones.
Can't miss it, really.  However, if you have trouble, call the telephone
number above, or call my pager, on 081-812-2661.

If it helps, we're in the direction of Buckingham Palace, which is
(very) partially visible from our windows.

If you wish to attend, you should bring a 3.5" DOS-formatted diskette
(sorry!  My UN*X machine is an Intergraph workstation, and I can't use
it for crypto) with a copy of your PGP 2.0+ public key.  I'll sign it
there.  Mac users: if you don't have Apple File Exchange (what!?), I'll
be extra nice and take your keys anyway ( ;-)) for AFE conversion on my
IIcx.  Not to fear.

It might not be a bad idea to copy your public key on each of several
diskettes, so you've got a copy to distribute to each of the others.
Don't trust me to copy *your* key to others!  As a matter of fact, as
there are plenty of power points in the meeting room, you should bring your
laptop, and/or a desktop PC:  when someone hands you a disk-with-key,
you can sign her key, and hand her back her diskette, with your own
pubkey added.

[Note to the novice: don't hand another person your secret key... the
 one named secring.pgp.  Read the documentation.]

This should be a lively meeting.  Among the topics likely to be
discussed are:

  o   The proliferation of public key cryptography in the U.K.
  o   The local development of anonymous remailers and a proposed
        automated public key repository at Demon Internet Systems
  o   Electronic networking/email security for the novice
  o   Pro-active proliferation of PGP 2.1+ to interesting European,
        African, and Asian sites
        -  ftp placement
        -  BBS distribution
        -  sneakernet across borders
  o   The use of HPACK in securing local file installations

.. and much more!

Mark Turner, from Demon Internet Systems, is likely to be on hand to
demo DIS for non-DIS users.  We've set up our own local, high-quality
newsgroups:
         demon.security
         demon.security.keys

and established the /pub/pgp and /pub/ibmpc/pgp archives on
gate.demon.co.uk (expanding recently to include all versions of PGP,
and interesting related files).

Hope to see you there!

Semper vigilans,
Semper vigilans,




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: yanek@novavax.nova.edu (Yanek Martinson)
Date: Thu, 31 Dec 92 16:02:03 PST
To: cypherpunks@toad.com
Subject: CFP'93 Electronic Brochure 1.2 (fwd)
Message-ID: <9301010001.AA16211@novavax.nova.edu>
MIME-Version: 1.0
Content-Type: text/plain


Forwarded message:

> From: Bruce R Koball <bkoball@well.sf.ca.us>
> 
>   The Third Conference on Computers, Freedom and Privacy -- CFP'93
> 9-12 March 1993, San Francisco Airport Marriott Hotel, Burlingame, CA
> 
> Sponsored by: Association for Computing Machinery, 
>               Special Interest Groups on:
>               Communications (SIGCOMM)
>               Computers and Society (SIGCAS)
>               Security, Audit and Control (SIGSAC)
> 
> Co-Sponsors and Cooperating Organizations:
> 
>       American Civil Liberties Union
>       American Library Association
>       Asociacion de Technicos de Informatica
>       Commission for Liberties and Informatics
>       Computer Professionals for Social Responsibility
>       Electronic Frontier Foundation
>       Freedom to Read Foundation
>       IEEE Computer Society
>       IEEE-USA Committee on Communications and Information Policy
>       Internet Society
>       Library and Information Technology Association
>       Privacy International
>       USD Center for Public Interest Law
>       U.S. Privacy Council
>       The WELL (Whole Earth 'Lectronic Link)
> 
> Patrons and Supporters (as of 24 December 1992):
> 
>       American Express Corp.
>       Apple Computer, Inc.
>       Dun & Bradstreet Corp.
>       Equifax, Inc.
>       Information Resource Service Company
>       Mead Data Central, Inc.
>       National Science Foundation (pending)
>       RSA Data Security, Inc.
> 
> 
> CFP'93 Electronic Brochure 1.2
> 

> 
> SCOPE:
> 
> The advance of computer and telecommunications technologies holds great 
> promise for individuals and society. From convenience for consumers and 
> efficiency in commerce to improved public health and safety and 
> increased participation in democratic institutions, these technologies 
> can fundamentally transform our lives.
> 
> At the same time these technologies pose threats to the ideals of a free 
> and open society. Personal privacy is increasingly at risk from invasion 
> by high-tech surveillance and eavesdropping. The myriad databases 
> containing personal information maintained in the public and private 
> sectors expose private life to constant scrutiny.
> 
> Technological advances also enable new forms of illegal activity, posing 
> new problems for legal and law enforcement officials and challenging the 
> very definitions of crime and civil liberties. But technologies used to 
> combat these crimes can pose new threats to freedom and privacy.
> 
> Even such fundamental notions as speech, assembly and property are being 
> transformed by these technologies, throwing into question the basic 
> Constitutional protections that have guarded them. Similarly, 
> information knows no borders; as the scope of economies becomes global 
> and as networked communities transcend international boundaries, ways 
> must be found to reconcile competing political, social and economic 
> interests in the digital domain.
> 
> The Third Conference on Computers, Freedom and Privacy will assemble 
> experts, advocates and interested people from a broad spectrum of 
> disciplines and backgrounds in a balanced public forum to address the 
> impact of computer and telecommunications technologies on freedom and 
> privacy in society. Participants will include people from the fields of 
> computer science, law, business, research, information, library science, 
> health, public policy, government, law enforcement, public advocacy and 
> many others.
> 

> 
> General Chair
> -------------
> Bruce R. Koball
> CFP'93
> 2210 Sixth Street
> Berkeley, CA 94710
> 510-845-1350 (voice)
> 510-845-3946 (fax)
> bkoball@well.sf.ca.us
> 
> Steering Committee
> ------------------
> John Baker                          Mitch Ratcliffe
> Equifax                             MacWeek Magazine
> 
> Mary J. Culnan                      Peter G. Neumann
> Georgetown University               SRI International
> 
> Dorothy Denning                     David D. Redell
> Georgetown University               DEC Systems Research Center
> 
> Les Earnest                         Marc Rotenberg
> GeoGroup, Inc.                      Computer Professionals
>                                     for Social Responsibility
> Mike Godwin
> Electronic Frontier Foundation      C. James Schmidt
>                                     San Jose State University
> Janlori Goldman
> American Civil Liberties Union      Barbara Simons
>                                     IBM
> Mark Graham
> Pandora Systems                     Lee Tien
>                                     Attorney
> Lance J. Hoffman
> George Washington University        George Trubow
>                                     John Marshall Law School
> Donald G. Ingraham
> Office of the District Attorney     Willis Ware
> Alameda County, CA                  Rand Corp.
> 
> John McMullen                       Jim Warren
> NewsBytes                           MicroTimes & Autodesk, Inc.
> 
> Simona Nass
> Student - Cardozo Law School
> 
> Affiliations are listed for identification only.
> 

> 
> Pre-Conference Tutorials:
> On Tuesday 9 March, the day before the formal conference begins, CFP'93
> is offering a number of in-depth tutorials on a wide variety of subjects
> on four parallel tracks. These presentations will range from interesting
> and informative to thought-provoking and controversial. The tutorials
> are available at a nominal additional registration cost.
> 
> Conference Reception:
> Following the Tutorials on Tuesday evening, you are invited to meet new 
> and old friends and colleagues at an opening reception. 
> 
> Single Track Main Program:
> The technological revolution that is driving change in our society has
> many facets and we are often unaware of the way they all fit together,
> especially the parts that lie outside of our own expertise and interest.
> The primary goal of CFP'93 is to bring together individuals from
> disparate disciplines and backgrounds, and engage them in a balanced
> discussion of all CFP issues. To this end our main program, starting on
> Wednesday 10 March, is on a single track enabling our attendees to take
> part in all sessions.
> 
> Registration is Limited:
> CFP'93 registration will be limited to 550 attendees, so we advise you 
> to register as early as possible and take advantage of the early 
> registration discounts.
> 
> Luncheons and Banquets:
> A key component of the CFP conferences has been the interaction between
> the diverse communities that constitute our attendees. To promote this
> interaction CFP'93 is providing three luncheons and evening two banquets
> with the cost of conference registration.
> 
> EFF Pioneer Awards
> All conference attendees are invited to the Awards Reception sponsored 
> by the Electronic Frontier Foundation (EFF) on Wednesday evening, 10 
> March. These, the second annual EFF Pioneer Awards, will be given to 
> individuals and organizations that have made distinguished contributions 
> to the human and technological realms touched by computer-based 
> communications.
> 
> Birds of a Feather Sessions:
> CFP'93 will provide a limited number of meeting rooms to interested 
> individuals for special Birds of a Feather sessions after the formal 
> program each evening. These sessions will provide an opportunity for 
> special interest discussions that were not included in the formal 
> program and will be listed in the conference materials. For further 
> information contact CFP'93 BoF Chair:
> 
>       C. James Schmidt
>       University Librarian
>       San Jose State University
>       One Washington Square
>       San Jose, CA 95192-0028
>       voice        408-924-2700
>       voice mail   408-924-2966
>       e-mail       schmidtc@sjsuvm1.sjsu.edu
> 

> 
> CFP'93 Featured Speakers:
> 
> Nicholas Johnson 
> 
> Nicholas Johnson was appointed head of the Federal Communications 
> Commission by President Johnson in 1966, serving a seven year term. In 
> his role as commissioner, he quickly became an outspoken consumer 
> advocate, attacking network abuses and insisting that those who use the 
> frequencies under the FCC license are the public's trustees. He has been 
> a visiting professor of law at the College of Law at the University of 
> Iowa since 1981 and is currently co-director of the Institute for 
> Health, Behavior and Environmental Policy at the University of Ohio.
> 
> Willis H. Ware
>  
> Willis H. Ware has devoted his career to all aspects of computer 
> science--hardware, software, architectures, software development, public 
> policy and legislation. He chaired the "HEW committee" whose report was 
> the foundation for the Federal Privacy Act of 1974. President Ford 
> appointed him to the Privacy Protection Study Commission whose report 
> remains the most extensive examination of private sector record-keeping 
> practices.  Dr. Ware is a member of the National Academy of Engineering, 
> a Fellow of the Institute of Electronic and Electrical Engineers, and a 
> Fellow of the American Association for Advancement of Science.
> 
> John Perry Barlow 
> 
> John Perry Barlow is a retired Wyoming cattle rancher, a lyricist for 
> the Grateful Dead, and a co-founder of the Electronic Frontier 
> Foundation. He graduated from Wesleyan University with an honors degree 
> in comparative religion. He writes and lectures on subjects relating to 
> digital technology and society, and is a contributing editor of numerous 
> publications, including Communications of the ACM, NeXTworld, 
> MicroTimes, and Mondo 2000.
> 
> Cliff Stoll
> 
> Cliff Stoll is best known for tracking a computer intruder across the 
> international networks in 1987; he told this story in his book, "The 
> Cuckoo's Egg" and on a Nova television production. He is less known for 
> having a PhD in planetary science, piecing quilts, making plum jam, and 
> squeezing lumps of bituminous coal into diamonds.
> 

> 
> CFP'93 Tutorials:
> 
> Tuesday 9 March - Morning Tutorials
> 
> Information Use in the Private Sector
> Jack Reed, Information Resource Service Company
> Diane Terry, TransUnion Corp.    Dan Jones, D.Y. Jones & Assoc.
> 
> This tutorial will deal with the use of personal information from the
> point of view of some private sector information vendors and users. It
> will include a discussion of the Fair Credit Reporting Act and the
> "Permissible Purposes" for obtaining a consumer credit report.
> Information used for purposes outside the FCRA will be discussed in
> relationship to privacy and societal needs for businesses and
> individuals.
> 
> Access to Government Information:
> James Love, Director, Taxpayer Assets Project
> 
> The tutorial will examine a wide range of problems concerning citizen 
> access to government information, including how to ask for and receive 
> information under the federal Freedom of Information Act, what types of 
> information government agencies store on computers, what the barriers 
> are to citizen access to these information resources, and how citizens 
> can change government information policy to expand access to taxpayer-
> funded information resources.
> 
> Exploring the Internet -- a guided journey
> Mark Graham, Pandora Systems	Tim Pozar, Late Night Software
> 
> This tutorial will give participants a practical introduction to the 
> most popular and powerful applications available via the world's largest 
> computer network, the Internet.  There will be hands-on demonstrations 
> of communications tools such as e-mail, conferencing, Internet Relay 
> Chat, and resource discovery and navigation aids such as Gopher, WAIS, 
> Archie and World Wide Web. Extensive documentation will be provided.
> 
> Constitutional Law for Non-lawyers (1/2 session):
> Mike Godwin, Staff Counsel, Electronic Frontier Foundation
> 
> This tutorial is designed to inform non-lawyers about the Constitutional 
> issues that underlie computer-crime and computer civil-liberties cases.  
> The tutorial focuses on the First and Fourth Amendments, but includes a 
> discussion of the Fifth Amendment and its possible connection to the 
> compelled disclosure of cryptographic keys. It also includes a 
> discussion of the appropriateness of "original intent" as a method for 
> applying the Constitution in the modern era.
> 
> Civil Liberties Implications of Computer Searches & Seizures (1/2 ses.):
> Mike Godwin, Staff Counsel, Electronic Frontier Foundation
> 
> This tutorial assumes only a very basic knowledge of Constitutional law 
> (the prior tutorial provides an adequate background), and outlines how 
> searches and seizures of computers may raise issues of First and Fourth 
> Amendment rights, as well as of federal statutory protections. It 
> includes a discussion of what proper search-and-seizure techniques in 
> such cases may be. 
> 

> 
> Tuesday 9 March - Afternoon Tutorials
> 
> Practical Data Inferencing: What we THINK we know about you.
> Russell L. Brand, Senior Computer Scientist, Reasoning Systems
> 
> What do your transaction trails reveal about you?  Are you a good risk 
> to insure?  Are you worth kidnapping, auditing or suing?  Which products 
> should I target at you?  Are you a member of one of those groups that I 
> would want to harass or discriminate against? This tutorial will be a 
> hands-on approach to digging for data and to piecing it back together.  
> Time will be divided between malicious personal invasions and sweeping 
> searches that seek only profit, followed by a brief discussion about 
> improper inferences and their practical impact on innocent files and 
> lives. Legal and moral issues will not be addressed.
> 
> Telecommunications Fraud
> Donald P. Delaney, Senior Investigator, New York State Police
> 
> Illegal call sell operations in New York City are estimated to be a 
> billion dollar industry. This tutorial will provide an overview of the 
> problem, from finger hacking to pay phone enterprises, and will include 
> an up-to-date assessment of the computer cracker/hacker/phone phreak 
> impact on telephone company customer losses. Also discussed will be 
> unlawful access of telephone company switches; unlawful wiretapping and 
> monitoring; cards, codes and 950 numbers; New York State law and police 
> enforcement; methods of investigation and case studies.
> 
> Private Sector Marketplace and Workplace Privacy 
> Ernest A. Kallman, Bentley College, H. Jeff Smith, Georgetown University
> 
> This tutorial will give participants a general overview of privacy 
> issues affecting uses of personal information (e.g., medical 
> information, financial information, purchase histories) in the 
> marketplace as well as privacy concerns in the workplace (e.g., privacy 
> of electronic and voice mail, work monitoring).  The tutorial will also 
> set the boundaries for privacy arguments in the middle and latter 1990s.
> 
> SysLaw
> Lance Rose, Attorney and Author "SysLaw"
> 
> The SysLaw tutorial session will explore in depth the freedom and
> privacy issues encountered by computer bulletin boards (BBS), their
> system operators and their users.  BBSs are estimated to number over
> 45,000 today (not counting corporate systems), and range from small,
> spare-time hobby systems to systems with thousands of users, grossing
> millions of dollars.  BBSs are a grassroots movement with an entry cost
> of $1,000 or less, and the primary vehicles for new forms of electronic
> communities and services. Subjects covered will include: First Amendment
> protection for the BBS as publisher/distributor; data freedom and
> property rights on the BBS; how far can sysops control BBS user
> activities?; and user privacy on BBSs today.
> 
> Note: Tutorial presenters will offer expert opinions and information.
> Some may advocate particular viewpoints and thus may put their own
> "spin" on the issues. Caveat Listener. 
> 

> 
> CFP'93 Main Program Sessions: 
> 
> Wednesday 10 March
> 
> Electronic Democracy
> Chair - Jim Warren, MicroTimes and Autodesk, Inc.
> 
> The effects of computer and telecommunications technologies on 
> democratic processes and institutions are increasing dramatically. This 
> session will explore their impacts on political organizing, campaigning, 
> access to representatives and agencies, and access to government 
> information that is essential for a free press and an informed 
> electorate.
> 
> Electronic Voting -- Threats to Democracy
> Chair - Rebecca Mercuri, University of Pennsylvania
> 
> This panel session will invite representatives covering a broad spectrum 
> of involvement with the controversial subject of electronic vote 
> tallying to address such issues as: Is a secure and reliable electronic 
> voting system feasible? What threats to these systems are identifiable? 
> Should electronic voting systems be open for thorough examination? Can 
> auditability be assured in an anonymous ballot setting? Can voting by 
> phone be practical and confidential? Did Congress exempt voting machines 
> from the Computer Security Act?
> 
> Censorship and Free Speech on the Networks
> Chair - Barbara Simons, IBM
> 
> As online forums become increasingly pervasive, the notion of "community 
> standards" becomes harder to pin down. Networks and BBSs will link--or 
> create--diverse, non-geographic communities with differing standards, 
> laws, customs and mores. What may be frank discussion in one forum may 
> be obscenity or defamation or sexual harassment in another. This session 
> will explore the questions of what kinds of freedom-of-speech problems 
> face us on the Net and what kinds of legal and social solutions we need.
> 
> Portrait of the Artist on the Net
> Chair - Anna Couey, Arts Wire
> 
> Computer forums and networks make possible both new artforms and new 
> ways of remote collaboration and exhibition. The growth of the Net 
> creates opportunities for the blossoming of dynamic and interactive 
> artforms and of artistic cultures -- provided that networks become 
> widely accessible and remain open to artistic expression without 
> political interference. This session will examine the potentials and the 
> problems of art and artists on the Net.
> 
> 

> 
> Thursday 11 March
> 
> Digital Telephony and Crypto Policy
> Chair - John Podesta, Podesta and Associates
> 
> The increasingly digital nature of telecommunications potentially 
> threatens the ability of law enforcement agencies to intercept them when 
> legally authorized to do so. In addition, the potential widespread use 
> of cryptography may render the ability to intercept a communication 
> moot. This session will examine these issues and the proposals that 
> have been put before Congress by law enforcement agencies to address 
> these perceived problems.
> 
> Health Records and Confidentiality
> Chair - Janlori Goldman, American Civil Liberties Union
> 
> As the new Administration and Congress consider proposals to reform the 
> United States health care system, it is imperative that confidentiality 
> and security safeguards be put in place to protect personal information. 
> Currently, no comprehensive legislation exists on the confidentiality of 
> health information. This session will explore the current and potential 
> uses of health care information, and proposals to safeguard the 
> information.
> 
> The Many Faces of Privacy
> Chair  - Willis Ware, Rand Corp.
> 
> Privacy at any cost is foolish, unwise and an untenable position, and 
> privacy at zero cost is a myth. This two-part session will explore the 
> balancing act between the two extremes and the costs and benefits that 
> accrue. The first part will present several examples of systems and 
> applications in the public and private sectors that stake out a position 
> in this continuum.   The second part will be a panel discussion 
> exploring the issues raised by the examples previously presented.
> 
> The Digital Individual
> Chair - Max Nelson-Kilger, San Jose State University
> 
> We are all represented by personal records in countless databases. As 
> these records are accumulated, disseminated and coalesced, each of us is 
> shadowed by an ever larger and more detailed data alter-ego, which 
> increasingly stands in for us in many situations without our permission 
> or even awareness. How does this happen? How does it affect us? How will 
> it develop in the future? What can we do? This session will investigate 
> these questions.
> 

> 
> Friday 12 March
> 
> Gender Issues in Computing and Telecommunications
> Chair - Judi Clark, Bay Area Women in Telecommunications
> 
> Online environments are largely determined by the viewpoints of their
> users and programmers, still predominantly white men. This panel will
> discuss issues of freedom and privacy that tend to affect women -- such
> as access, identity, harassment, pornography and online behavior -- and
> provide recommendations for gender equity policies to bulletin board
> operators and system administrators.
> 
> The Hand That Wields the Gavel
> Chair - Don Ingraham, Asst. District Attorney, Alameda County, CA
> 
> An inevitable result of the settlement of Cyberspace is the adaptation
> of the law to its particular effects. In this session  a panel of
> criminal lawyers addresses the fallout from a hypothetical computer
> virus on the legal responsibilities of system managers and operators.
> The format will be a simulated court hearing. Attendees will act as
> advisory jurors in questioning and in rendering a verdict.
> 
> The Power, Politics, and Promise of Internetworking
> Chair- Jerry Berman, Electronic Frontier Foundation
> 
> This session will explore the development of internetworking 
> infrastructures, domestically and worldwide. How will this 
> infrastructure and its applications be used by the general public?  What 
> will the global network look like to the average user from Kansas to 
> Kiev?  How will politics, technology and legislation influence the 
> access to, and cost of, the Net?  How can the potential of this powerful 
> medium be fully realized?
> 
> International Data Flow
> Chair - George Trubow, John Marshall Law School
> 
> The trans-border flow of information on international computer networks 
> has been a concern for governments and the private sector. In addition 
> to concerns for privacy and data security, the economic and national 
> security implications of this free flow of information among scientists, 
> engineers and researchers around the world are also cause for concern. 
> This session will assemble a number of speakers to compare the various 
> perspectives on the problem 
> 
> 

> 
> Some of the Speakers in the CFP'93 Main Program: 
> 
> Phillip E. Agre, Dept. of Communication, Univ. of California, San Diego
> Jonathan P. Allen, Dept. of Information & Computer Science, 
>       University of California, Irvine
> Sheri Alpert, Policy Analyst, author: "Medical Records, Privacy, and 
>       Health Care Reform"
> William A. Bayse, Assistant Director, Federal Bureau of Investigation
> William Behnk, Coordinator, Legislative Information System, State of 
>       California
> Paul Bernstein, Attorney
> Kate Bloch, Hastings College of the Law
> Anita Borg, DEC Network Systems Lab
> Richard Civille, Computer Professionals for Social Responsibility
> Roger Clarke, Reader in Information Systems, Department of Commerce, 
>       Australian National University
> Dorothy Denning, Chair, Computer Science Department, Georgetown 
>       University
> Janet Dixon, Stanford Linear Accelerator Center
> Robert Edgar, Simon and Schuster Technology Group
> Kathleen Frawley, American Health Information Management Association
> Emmanuel Gardner, District Manager, Government Affairs, AT&T 
> Mike Godwin, Staff Counsel, Electronic Frontier Foundation
> Joe Green, University of Minnesota
> Sarah Grey, Computer Department, We The People, Brown presidential 
>       campaign organization (invited)
> Will Hill, Bellcore
> Carl Kadie, Co-editor, Computers and Academic Freedom News newsletter
> Mitch Kapor, Chairman, Electronic Frontier Foundation
> David Lewis, Deputy Registrar, Department of Motor Vehicles, 
>       Commonwealth of Massachusetts
> James Love, Director, Taxpayers Assets Project
> Judy Malloy, Associate Editor, Leonardo Electronic News
> Irwin Mann, Mathematician, New York University
> David McCown, Attorney
> Rob Mechaley, Vice President, Technology Development, McCaw Cellular 
>       Communications, Inc.
> Robert Naegele, Granite Creek Technology Inc., Voting Machine Examiner, 
>       consultant to NY State
> Barbara Peterson, Staff Attorney, Joint Committee on Information 
>       Technology Resources, Florida Legislature
> Jack Reed, Chairman, Information Resource Service Company
> Virginia E. Rezmierski, Assistant for Policy Studies to the Vice 
>       Provost for Information Technology, University of Michigan
> Jack Rickard, Editor, Boardwatch Magazine
> Randy Ross, American Indian Telecommunications
> Roy Saltman, National Institute of Standards and Technology
> Robert Ellis Smith, Publisher, Privacy Journal
> David Sobel, Computer Professionals for Social Responsibility
> Ross Stapleton, Research Analyst, Central Intelligence Agency
> Jacob Sullum, Associate Editor, Reason Magazine
> Greg Tucker, Coordinator, David Syme Faculty of Business, 
>       Monash University, Australia
> Joan Turek-Brezina, Chair, Health and Human Services Task Force on 
>       Privacy of Private-Sector Health Records
> 

> 
> Registration:
> Register for the conference by returning the Conference Registration
> Form along with the appropriate payment. The registration fee includes
> conference materials, three luncheons (Wednesday, Thursday and Friday),
> two banquet dinners (Wednesday and Thursday) and evening receptions
> (Tuesday, Wednesday and Thursday). Payment must accompany registration.
> 
> Registration Fees are: 
>       If mailed by:       7 February        8 March         on site 
>       Conference Fees:      $300             $355             $405
>       Tutorial Fees:        $135             $165             $195
>       Conference & Tutorial $435             $520             $600
> 
> Registration is limited to 550 participants, so register early and save!
> 
> By Mail:                               By Fax:
> (with Check or Credit Card)            (with Credit Card only)
> CFP'93 Registration                    Send Registration Form
> 2210 Sixth Street                      (510) 845-3946
> Berkeley, CA 94710                     Available 24 hours
> 
> By Phone:                              By E-Mail:
> (with Credit Card only)                (with Credit Card only)
> (510) 845-1350                         cfp93@well.sf.a.us
> 10 am to 5 pm Pacific Time
> 
> CFP'93 Scholarships:
> The Third Conference on Computers, Freedom and Privacy (CFP'93) will 
> provide a limited number of full registration scholarships for students 
> and other interested individuals. These scholarships will cover the full
> costs of registration, including three luncheons, two banquets, and all
> conference materials. Scholarship recipients will be responsible for
> their own lodging and travel expenses. Persons wishing to apply for one
> of these fully-paid registrations should contact CFP'93 Scholarship
> Chair, John McMullen at:  mcmullen@mindvox.phantom.com
> 
> Hotel Accommodations:
> The Third Conference on Computers, Freedom and Privacy will be held at 
> the San Francisco Airport Marriott Hotel in Burlingame, CA. This 
> facility is spacious and comfortable, and is easily accessible from the 
> airport and surrounding cities. Because of the intensive nature of the 
> conference, we encourage our attendees to secure their lodging at the 
> conference facility. Special conference rates of $99/night, single or 
> multiple occupancy, are available. Our room block is limited and these 
> conference rates are guaranteed only until 9 February 1993, so we urge 
> you to make your reservations as early as possible. When calling for 
> reservations, please be sure to identify the conference to obtain the 
> conference rate. Hotel Reservations: (415) 692-9100 or (800) 228-9290. 
> 
> Refund Policy:
> Refund requests received in writing by February 19, 1993 will be 
> honored. A $50 cancellation fee will be applied. No refunds will be made 
> after this date; however, you may send a substitute in your place.
> 

> Registration Form
> 
> Name (Please print):__________________________________________________
> 
> Title:________________________________________________________________
> 
> Affiliation:__________________________________________________________
> 
> Mailing Address:______________________________________________________
> 
> City, State, Zip:_____________________________________________________
> 
> Country:______________________________________________________________
> 
> Telephone:_____________________________Fax:___________________________
> 
> E-mail:_______________________________________________________________
> 
> Privacy Locks:
> We will not sell, rent, loan, exchange or use this information for any 
> purpose other than official Computers, Freedom and Privacy Conference 
> activities. A printed roster will be distributed to attendees. Please 
> indicate the information you wish to be excluded from the roster:
>       __Print only name, affiliation and phone number
>       __Print name only
>       __Omit all information about me in the roster
> 
> Registration Fees  (please indicate your selections):
>       If mailed by:       7 February         8 March         on site 
>       Conference Fees:      $300__            $355__          $405__
>       Tutorial Fees         $135__            $165__          $195__
>       Conference & Tutorial $435__            $520__          $600__
> 
> If you have registered for the Tutorials, select one from each group:
> 9:00 AM - 12:00 Noon 
>       __Information Use in Private Sector
>       __Constitutional Law for Non-lawyers & Civil-liberties 
>           Implications of Computer Searches and Seizures
>       __Access to Government Information
>       __Exploring the Internet
> 
> 1:30 PM - 4:30 PM
>       __Practical Data Inferencing: What we THINK we know about you.
>       __Telecommunications Fraud
>       __Private Sector Marketplace and Workplace Privacy 
>       __SysLaw
> 
> Payments:        Total Amount____________
> 
> Please indicate method of payment:     __Check (payable to CPF'93)
> (payment must accompany registration)  __VISA
>                                        __MasterCard
> 
> Credit card #______________________________Expiration date____________
> 
> Name on card__________________________________________________________
> 
> Signature_____________________________________________________________
> 

> 


--
Yanek Martinson    mthvax.cs.miami.edu!safe0!yanek     uunet!medexam!yanek
this address preferred -->> yanek@novavax.nova.edu <<-- this address preferred
Phone (305) 765-6300 daytime   FAX: (305) 765-6708  1321 N 65 Way/Hollywood
      (305) 963-1931 evenings       (305) 981-9812  Florida, 33024-5819




From cypherpunks@MHonArc.venona  Wed Dec 17 23:17:14 2003
From: jim@RSA.COM (Jim Bidzos)
Date: Tue, 22 Dec 92 15:12:44 EST
To: mrr@scss3.cl.msu.edu
Subject: RIPEM message for your approval
In-Reply-To: <9212221821.AA16897@scss3.cl.msu.edu>
Message-ID: <9212222010.AA22792@RSA.COM>
MIME-Version: 1.0
Content-Type: text/plain




Mark-

As you can imagine, many changes have been proposed, and, I think,
some good ones incorporated, in the most current form of the RSAREF
license. These changes are based on constructive comments from over
twenty people. These changes may encourage folks to distribute RSAREF
and RIPEM who otherwise would not have.

We plan to make all RSAREF applications (such as RIPEM) availble WITH
RSAREF.  Why shouldn't someone get all the stuff built on it if they
get RSAREF? (Including helpful code such as the Thompson/Schiller
emacs adapter.) I assume you have no objection.

I'm hopeful that you see these changes as positive; please let me know
if that's not true! I offer a summary of them, the rationale,
perceived benefits, and a complete copy of the revised license.

------------------------------------------------------------------

Here's a summary of the changes between what's attached (the one we
plan to now "standardize" on for RSAREF) and what you sent me:

changed 1(a) and added (8): the license is now perpetual. Some have
claimed RSA might "suddenly" decide to cancel RSAREF licenses. It is
now crystal clear that the license can only be cancelled by violating
the agreement. RSA cannot cancel it at its discretion. And even if you
violate it, it doesn't cancel the license of those who got it from
you. I think this is an importnat clarification, from what I've heard.

changed 1(c) and added 2(d): We don't care about any porting or
performance mods, but we don't feel we should allow automatic access
under the normal interface. We've granted it to you since RIPEM
predates RSAREF (also to John Gilmore for a secure RLOGIN using
Diffie-Hellman) and we'll grant it to anyone for any reasonable use.
(We state so in the Agreement.)  We just want to know what it is we're
allowing to go around the interface.

End of Section 1 - a clarification in the form of an addition is made
here. Some have said that unrelated software on a tape with RSAREF
could be covered by the restrictions imposed on RSAREF Application
Programs. This should clear that up. (I believe this helps you in the
separate distribution of the RIPEM code minus the RSAREF code.)

changed (6): We simply have removed RSA's $5,000 cap on protecting
RSAREF users against charges from some other patent holders. (Like
PKP!) Some have claimed that RSAREF was posibly a way to "set up"
users for PKP (the patent holders) since $5K was hardly enough to
defend against patent infringement.  (They actually thought RSAREF was
a way to get people to infringe just so that PKP could sue them! RSA
pays $5,000, but PKP collects more, therefore it's a 'you hold em, and
I'll hit em' thing, or so I guess they thought.) I believe this makes
it clear we intend to sue no one for using RSAREF, and in fact defend
users ALL THE WAY if someone else does.

I think these are all for the better, and will engender trust in RSA's
intentions with RSAREF, to support free PEM.

---------------------------------------------------------------------

New RSAREF License  (December 1992 version)

----------------------------------------------------------------------
                           RSA LABORATORIES
                      PROGRAM LICENSE AGREEMENT



RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA")
GRANTS YOU A LICENSE AS FOLLOWS TO THE "RSAREF" PROGRAM:

1.   LICENSE. RSA grants you a non-exclusive, non-transferable,
     perpetual (subject to the conditions of section 8) license
     for the "RSAREF" program (the "Program") and its associated
     documentation, subject to all of the following terms and
     conditions:

     a.   to use the Program on any computer in your possession;

     b.   to make copies of the Program for back-up purposes;

     c.   to modify the Program in any manner for porting or
          performance improvement purposes (subject to Section 2)
          or to incorporate the  Program into other computer programs 
          for your own personal or internal use, provided that you 
          provide RSA with a copy  of any such modification or 
          Application Program by electronic mail, and grant RSA 
          a perpetual, royalty-free license to use and distribute 
          such modifications and Application Programs on the terms 
          set forth in this Agreement.

     d.   to copy and distribute the Program and Application Programs
          in accordance with the limitations set forth in Section 2.

"Application Programs" are programs which incorporate all or any
portion of the Program in any form. The restrictions imposed on
Application Programs in this Agreement shall not apply to any software
which, through the mere aggregation on distribution media, is
co-located or stored with the Program.

2.   LIMITATIONS ON LICENSE.

     a.   RSA owns the Program and its associated documentation and
          all copyrights therein. You may only use, copy, modify and
          distribute the Program as expressly provided for in this
          Agreement. You must reproduce and include this Agreement,
          RSA's copyright notices and disclaimer of warranty on any
          copy and its associated documentation.

     b.   The Program and all Application Programs are to be used only
          for non-commercial purposes. However, media costs associated
          with the distribution of the Program or Application Programs
          may be recovered.

     c.   The Program, if modified, must carry prominent notices
          stating that changes have been made, and the dates of any
          such changes. 

     d.   Prior permission from RSA is required for
          any modifications that access the Program through ways
          other than the published Program interface or for 
          modifications to the Program interface. RSA will grant
          all reasonable requests for permission to make such
          modifications.

3.   NO RSA OBLIGATION. You are solely responsible for all of your
     costs and expenses incurred in connection with the distribution
     of the Program or any Application Program hereunder, and RSA
     shall have no liability, obligation or responsibility therefor.
     RSA shall have no obligation to provide maintenance, support,
     upgrades or new releases to you or to any distributee of the
     Program or any Application Program.

4.   NO WARRANTY OF PERFORMANCE. THE PROGRAM AND ITS ASSOCIATED
     DOCUMENTATION ARE LICENSED "AS IS" WITHOUT WARRANTY AS TO THEIR
     PERFORMANCE, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR
     PURPOSE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF
     THE PROGRAM IS ASSUMED BY YOU AND YOUR DISTRIBUTEES. SHOULD THE
     PROGRAM PROVE DEFECTIVE, YOU AND YOUR DISTRIBUTEES (AND NOT RSA)
     ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR
     CORRECTION.

5.   LIMITATION OF LIABILITY. EXCEPT AS EXPRESSLY PROVIDED FOR IN
     SECTION 6 HEREINUNDER, NEITHER RSA NOR ANY OTHER PERSON WHO HAS
     BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE
     PROGRAM SHALL BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR ANY
     DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF RSA HAS BEEN
     ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

6.   PATENT INFRINGEMENT OBLIGATION. Subject to the limitations set
     forth below, RSA, at its own expense, shall: (i) defend, or at
     its option settle, any claim, suit or proceeding against you on
     the basis of infringement of any United States patent in the
     field of cryptography by the unmodified Program; and (ii) pay
     any final judgment or settlement entered against you on such
     issue in any such suit or proceeding defended by RSA. The
     obligations of RSA under this Section 6 are subject to: 
     (i) RSA's having sole control of the defense of any such claim, 
     suit or proceeding; (ii) your notifying RSA promptly in writing
     of each such claim, suit or  proceeding and giving RSA authority
     to proceed as stated in this  Section 6; and (iii) your giving 
     RSA all information known to you relating to such claim, 
     suit or proceeding and cooperating  with RSA to defend any such 
     claim, suit or proceeding. RSA shall have no obligation under 
     this Section 6 with respect to any claim to the extent it is 
     based upon (A) use of the Program  as modified by any person 
     other than RSA or use of any Application Program, where use 
     of the unmodified Program would not constitute an infringement, 
     or (B) use of the Program in a manner other than that permitted 
     by this Agreement.  THIS SECTION 6 SETS FORTH RSA'S ENTIRE 
     OBLIGATION AND YOUR EXCLUSIVE REMEDIES CONCERNING CLAIMS FOR  
     PROPRIETARY RIGHTS INFRINGEMENT.

     NOTE: Portions of the Program practice methods described in and
     subject to U.S. Patents Nos. 4,200,770, 4,218,582 and 4,405,829,
     and all foreign counterparts and equivalents, issued to Leland
     Stanford Jr. University and to Massachusetts Institute of
     Technology. Such patents are licensed to RSA by Public Key
     Partners of Sunnyvale, California, the holder of exclusive
     licensing rights. This Agreement does not grant or convey any
     interest whatsoever in such patents.

7.   RSAREF is a non-commercial publication of cryptographic
     techniques. Portions of RSAREF have been published in the
     International Security Handbook and the August 1992 issue of Dr.
     Dobb's Journal. Privacy applications developed with RSAREF may be
     subject to export controls. If you are located in the United States
     and develop such applications, you are advised to consult with the
     State Department's Office of Defense Trade Controls.

8.   TERM. The license granted hereunder is effective until
     terminated. You may terminate it at anytime by destroying
     the Program and its associated documentation. The termination
     of your license will not result in the termination of the
     licenses of any distributees who have received rights to the
     Program through you so long as they are in compliance with
     the provisions of this license.


-----------------------------------------------------------------










